Re: something for pci.lst
Am Mon, den 26.01.2004 schrieb David Nusinow um 23:56:
> 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:
I'm not really sure if it's worth the effort. I think we wuld better put
our limited time into fixing the already reported discover1 issues and
providing discover2 packages (I will work on the latter tomorrow).
> 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.
I think the easiest would be to make the to packages conflict and
document this in README.Debian.