Re: Inclusion of kernel version in kernel package names: A followup
On 12 May 1996, Manoj Srivastava wrote:
> One, since each new kernel version essentially creates a new
> orthogonal package (so kernel-image-1.3.95 does not conflict with
> or replace kernel-image-1.3.97), and kernel image packages are
> marked essential, it is not easy to remove kernel-image-1.3.95 when,
> say, kernel-image-2.0.2 comes out. In fact, you have to use dpkg
> --force-remove-essential to do so.
>
> This is maybe not of consequence to seasoned users, but this is less
> than a satisfactory situation. However, removing the essential flag
> does not seem to be the solution, since it _is_ essential to have at
> least one kernel image on the system.
an idea:
make kernel-image-*.*.* "Provides: kernel-image", and get one or more of
the maintainers of the essential base packages have "Depends:
kernel-image".
Will dpkg or dselect handle this correctly? i.e. will removing only one
kernel-image-x.x.x file remove the virtual package kernel-image, or will
that stick around until the last kernel-image-y.y.y is removed?
Personally, I think it's a mistake to have the kernel image flagged as
essential, anyway. The base install disks already install a kernel. The
latest install disks have a much later kernel (1.3.95) than what was
available on the ftp site (1.3.64), though this will change now that
source & image packages are available for 1.3.97...
If someone wants to try to run without a kernel, let them :-)
The "Provides: kernel-image" may even be able to do what you want with
version number dependancy, too.
Can't see that that would be much use though. I think it's not worth the
effort to spend too much time on...applications are dependant on what
version of the kernel is currently RUNNING, not on what version of the
kernel may be installed in /boot.
e.g. 1.3.97 may be installed, but the system was booted on 1.2.13. Not an
uncommon scenario.
It's up to the user to make sure that they're running the right kernel for
whatever software they want to run. I think it's way beyond the scope of
dpkg to try to manage this.
Craig
Reply to: