On Sunday 13 January 2008, Petter Reinholdtsen wrote: > [Frans Pop] > > - 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? Probably not for my desktop on which I tried it. What happens with packages that are already installed? Are they listed or are they skipped? If they are skipped the problem is of course that I don't know what packages it would have listed that I already have installed... Maybe an option is needed to just list packages and their status (or is that the -l option already; also lists only 915resolution). (And I just see that discover-pkginstall is missing a man page and --help/-h options.) > 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. :) I would think having it called from pkgsel (which also calls tasksel) would be the most logical option. Probably as a separate stage after tasksel has been run. Doing it in hw-detect doesn't really make any sense to me as basically it's the wrong phase of the installation. I doubt You'll be getting any patches to discover from me, but I am willing to work on integration in pkgsel (though only if there is someone willing to at the same time work on any needed changes in discover) and to provide feedback (as now). > > 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. [...] So neither discover nor discover1 currently install init scripts? Did discover1 already contain code to remove existing init scripts on upgrade or not? If not then I guess that needs to be added now, but it would also mean that it is useful to warn users who still have the init script installed. If it did, then there should be no need to add it for the transition. > > 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. In that case I strongly suggest dropping discover-modprobe from the package. If discover-config still needed when that is gone? > > 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. Then discover-data (and probably the discover program itself) should IMO be trimmed so that it only contains data/functionality needed to support _that_ feature. Not straight away, but it should be done at some point. > I hope it is a bit clearer now. Yep. Thanks for the info.
Attachment:
signature.asc
Description: This is a digitally signed message part.