[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Time to migrate discover1 users to discover v2

On Saturday 12 January 2008, Petter Reinholdtsen wrote:
> Discover v2 on the other hand have the new features to map
> hardware to debian packages for installation, and this feature should
> be part of the default Debian installation, I believe.  To test it
> yourself, install discover and run discover-pkginstall as root.

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)
- I was (only) offered 915resolution, but AFAIK that package is no longer
  needed with current Intel XOrg drivers

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, ...)?

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 hope I got it right.  I implemented two transition packages
> discover1 and libdiscover1-dev, and added code to remove the
> /etc/init.d/discover file.

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)?

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.

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.
1) A "discover" package that really replaces discover1 and still includes
   the init script. The package should probably contain a README.Debian
   and display a message on upgrade informing users that if they have udev
   installed they should probably just purge the package.
2) A "discover-pkginstall" package that is to be used by D-I.

> Any objections to me uploading a new version of discover to take over
> discover1?  If not, I will upload tomorrow.

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?

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.


[1] http://gravityboy.livejournal.com/40620.html
[2] http://packages.debian.org/sid/xserver-xorg

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: