Re: Time to migrate discover1 users to discover v2
[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
Reply to: