[Frans Pop] > Just done that and noticed three issues: > - the dialog allowing selection of packages does not have a title > - the dialog should have a cancel button (enable backup capability)
Good ideas. I'll try to implement them. > - I was (only) offered 915resolution, but AFAIK that package is no > longer needed with current Intel XOrg drivers Aha. Feedback (as it BTS reports against the discover-data package) is needed with information on what hardware should map to which packages. I've added the ones I knew about, but lots are missing and some might be wrong. Are there other packages that should be installed for your hardware? > Could you give an overview of what hardware/packages > discover-pkginstall currently supports, what detection methods it > supports and what types of installs it can do (plain package > install, module build from source, ...)? It uses discover, and support the hardware handled by discover. Currently only the PCI and USB list contain mappings to debian packages. It can handle plain package installs, and packages using module-assistant to build kernel modules. The latter is built automatically when installed. > Could you also do a proposal how discover-pkginstall could be > integrated in the installation process? Do you think it should be > run quietly (just install the suggested packages by default; only > prompt at medium priority or lower), or should the user always be > prompted? If the last, shouldn't it also display at least package > short descriptions? I suspect that discover-pkginstall will need > changes before it becomes usable from within D-I. I am not quite sure. Either it could be called by hwdetect, or tasksel, or some other package. I believe it should be installed silently, or perhaps a question with everything detected enabled at medium debconf priority to allow expert install to drop some of the proposed packages. Perhaps it should include package description. Did not consider that so far. Patches are very welcome. :) > What exactly is the transition? Exactly what of the old discover1 > functionality is still left and what part of that is still actually > needed by anyone (see also X.Org info below)? The transition is dropping discover1 and moving all users of discover1 to use discover instead. > Also, I would guess that on some systems (that don't use udev for > whatever reason) just removing the init script on an upgrade from > Etch to Lenny could cause hardware support issues on reboot. Dropping the init.d script was done earlier for both discover and discover1, so the new code to remove it now was just to make sure upgrades from discover1 in Etch get this change even if the upgrade is to the transition package. And yes, those not using udev and instead uses discover will have issues after an reboot. This is not as much because the init.d script is gone, but mostly because the mapping from hardware to kernel modules are no longer being updated, as the information provided by the kernel and used by udev is of much higher quality, so it make no sense trying to compete with it. Those who do not want to use udev will have to load the modules they need manually, or show up to help us maintain the kernel module info in discover-data, or use some other method that is using the information provided by the kernel. Discover is not the tool for them any more, as we do not have the map-power nor will to keep that data up-to-date. We stopped maintaining that before Etch was released. > I guess basically my question is whether the old discover > functionality as a "boot time hardware detection utility" is still > relevant for anybody. If it is, then maybe the discover package > should be really be split in two separate packages. I believe that functionality is useless with discover, as the alternative is much better, always up-to-date and in sync with the used kernel. Because of this, I am no longer updating the hardware->kernel module mapping in discover-data. The mapping from hardware to X driver was useful until recently, when the X.org packages stopped using discover and handled this internally. > 2) A "discover-pkginstall" package that is to be used by D-I. This is as far as I know the only unique and really useful feature left in discover. > From a recent blog by David Nusinow [1] I understand that X.Org has > moved away from needing discover for X hardware detection. And > indeed, it is no longer listed as a dependency [2]. > > Wouldn't it be good to obsolete that part of discover's > functionality at the same time as this change? Perhaps, but that is not part of discover, it is part of discover-data. And to obsolete that functionallity would simply be to remove that information from discover-data, which I have not seen the point of doing yet, but will probably do some time in the future. For now, it make sense to be able to backport discover-data to Etch for those that want updated X.org detection information. > Basically, I have no real objection to an upload and don't actually > care all that much as discover isn't really used anywhere ATM, but > OTOH I miss the real plan behind the proposal. I hope it is a bit clearer now. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
