discover(2) and discover1

[Holger Levsen]

Hi,

a discussion about discover(2) and discover1 on the d-i irc channel 
(#debian-boot):

* h01ger is again confused about discover: is discover1 still used by d-i or 
does d-i now use discover (which is discover2)

<bubulle_> h01ger: discover1-data is used by xorg

<h01ger> and d-i uses?

<pere> h01ger: d-i uses discover1 too, as far as I know.  but it is moving to 
use the info in /lib/modules/ instead.

<pere> h01ger: there are historical reasons for this.

<bubulle_> pere: not sure we still use discover1....but, well, this is not 
really my part. What I can tell is "discover1 stuff moves very slowly....too 
slowly for being a critical thing in d-i"

<h01ger> pere, what for are you maintaining discover(2) then?

<h01ger> =where is it used?

<pere> we planned a long time ago to move to discover v2 from discover v1, but 
for that to happen we needed to update the discover-data v2 database.  this 
did not happen until a few weeks ago, when I started doing it.

<pere> so now the discover-data database is better than the discover1-data 
database, and it can be used to generate a discover1-data database

* bubulle_ leaves as pere knows indeed much mor ethan me here..:)

<pere> next, we planned to move d-i to discover v2, but this proved 
problematic, as the discover v2 binary was larger than the discover v1 
binary, and the discover-data v2 database was larger than the discover1-data 
database.  In short, it did not fit on the d-i floppy any more.

<pere> since then, the curl support in discover v2 udeb has been dropped, so 
the binary size is smaller.

<pere> the database size issue can be adressed by implementing support in 
discover v2 for compressed XML files.  this is not yet done.

<pere> in the short term, if d-i is still using discover v1, I believe it is 
better to drop the separate discover1-data package, and generate it using the 
discover-data v2 database instead.  this way we get a small binary and an 
updated database using the same database source.

<h01ger> ah. i'm asking because fai is still using discover1 - and 
discover-pkginstall sounds like a feature i want :) 

<pere> after all, d-i is going to drop discover1 any day now, unless it 
already happen, so it is not much use wasting time to shrink discover v2.

* h01ger nods the short term plan

<pere> there is a slight hickup for the short term plan, thought.  the xml2lst 
script used to generate the v1 database from the v2 data is slightly broken, 
and do not generate a good kernel 2.4 database for discover v1.

<h01ger> kernel 2.4 is not for interest for etch anymore

<h01ger> well, it is.

<h01ger> (2.4 is supposed to be supported but not shipped)

<pere> this is not very important, as 2.4 isn't that vital any more, but the 
bug is really in the code handling various kernel versions, so the problem 
will be more and more important as we try to support a wider range of kernel 
versions.

<pere> so if you are good with pythong and want to have a look, I would very 
much like some help. :)

* h01ger takes a mental note: i need to hide from pere - not ask him stuff :)

<h01ger> pere, thanx!

<pere> h01ger: :P

<pere> also, I need to coordinate the discover1-data removal with otavio, 
which has done most of the work on it lately.

<pere> h01ger: I would love to hear your experiences with the 
discover-pkginstall script.  It is as far as I know only tested by me so 
far. :)

<pere> bubulle_: and if you have time to review the template used, and propose 
a better text, I am willing to make it translatable. :D

<pere> h01ger: is fai using discover1 for kernel module loading, or for X 
video detection?  If the latter, I strongly recommend discover v2.

<h01ger> pere, for both

<h01ger> pere, i'll forward this log to the fai-devel list, ok?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.uni-koeln.de/pipermail/linux-fai-devel/attachments/20060904/daa9365c/attachment.bin