Re: Kernel dependencies
osd1000@tacitus.greenend.org.uk (Owen S. Dunn) wrote on 20.12.96 in <[🔎] m0vbDhG-000LG8C@tacitus.greenend.org.uk>:
> In article <[🔎] Pine.LNX.3.95.961220083855.7066A-100000@waterf.org> you write:
> >It would be nice to be able to do the followig dependency
> >
> >Depends: kernel (>=2.1.16)
>
> Indeed it would, especially in the case of people who don't use Dabian
> packaged kernels, where a dependency on kernel-image (or whatever)
> would be useless.
Dpkg dependencies are simply the wrong way for this.
The problem here is that on Linux, some people (make that a lot of people)
like to change their kernel fairly often. These same people often have
kernels of several different versions around, and actually use them.
Now, if we want to support these people (which I take as a given), then we
can't use kernel version dependencies. They don't do what we need.
Oh, we can have a module ninary depend on a specific kernel version,
though even that is of limited usefulness. But for stuff like bridging
utilities, this simply doesn't work. What is someone supposed to do who
uses both an 2.1.x experimental kernel (to experiment) and an 2.0.x stable
kernel (for when he isn't experimenting)?
I just had this idea - it probably needs work before it can become
useable:
Have some sort of database which tells about kernel dependencies of stuff,
and make sure the several incompatible versions of this stuff can actually
coexist. Then on boot, have some program generate version-dependant
symlinks from this database.
This is similar to the module stuff, but is more aimed at dependencies
like "this works for kernel versions 1.3.67 - 2.0.15 and 2.1.0 - 2.1.7".
Comments?
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: