Re: something for pci.lst
On Mon, Jan 26, 2004 at 09:22:24PM +0100, Gaudenz Steinlin wrote:
> Discover2 will have a general mechanism to avoid these name conflicts.
> The hardware database has a field for the kernel version.
>
> Beside this (which technically has nothing to do with kernel 2.6) there
> is nothing I know of which is better suited for 2.6 in discover2 as in
> discover1. By it's very design either discover1 nor discover2 should
> depend on the kernel version. Only the discover-data packages could
> depend on the kernel version.
>
> One solution for this problem in discover1 would be to have a
> discover-data-2.6 package.
Ok, I'm willing to set up a discover-data-2.6 package, as well as
provide a new version of discover-data where both Provides:
discover-data. It's kind of a hack, but I think it'd be worth it for
people customizing the sarge version of d-i. I see a few problems with it
up front though:
1) When we move to discover2 in sid, we'd have to move the
discover-data package to discover-data-2.4. I think I'll actually have
both current discover-data packages Provides: discover1-data instead,
and the new discover to depend on that. That should help plan for this
issue, minimizing its impact.
2) Getting discover-data-2.6 in good enough shape might be difficult in
a short time span, but it's certiantly feasible for our current needs.
3) I don't see any clean method to allow the 2.4 and 2.6 packages to
coexist. I suppose doing some more hacky garbage with symlinks and a
debconf question (the way the *dm packages now do) is an option that
I'd be willing to throw together.
It sounds really ugly when I weigh it all out, but again, I'm willing to
do the work if people will use it. It also gives me extra incentive to
help get discover2 in to sid so as to make this mess disappear as
quickly as possible :-) Any thoughts?
- David Nusinow
Reply to: