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

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.
OK.
> 
>  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. 

Gaudenz



Reply to: