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

Inclusion of kernel version in kernel package names: A followup


	A couple of weeks ago, I proposed a scheme (inspired by Bruce
 Perens) for allowing multiple versions of kernel sources and images
 to co-exist on any system. This was in some way incorporating prior
 art; lots of people like having a known fall-back version available
 for emergencies in case a new version is Kaput, and I like the part
 when /usr/src/linux is relinked to older sources if you remove the
 latest (possibly buggy) version of the source. I received no feedback
 on that, and assuming that to be good news, this scheme has been
 incorporated into the newer kernel packages (look at
 /usr/doc/kernel-source/LinkPolicy for the text of that message).

	However, there are a couple of consequences to this scheme
 that I thought I should point. 

	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.

	Secondly, since the actual name of the package is
 Name: kernel-image-1.3.95 Version: 1.3.95-0, there maybe versions
 1.3.95-2, 1.3.95-4, etc, there never will be kernel-image-1.3.95
 version 1.3.97-0. Oh dear, I'm rambling. What I mean is, how do I say
 my package foo will need kernel-image, version 1.3.96 or above? 

	Can I say foo needs virtual package kernel-image, >> 1.3.95 ?
 Ian? or is this abusing the virtual package paradigm?

 who sometimes feels that nobody reads his messages since they are too
 long and rambling.
"IBM: It may be slow, but it's hard to use."  -- Andrew Tannenbaum
<trb@ima.ima.isc.com>, author of Minix and Amoeba %%
Manoj Srivastava               Systems Research Programmer, Project Pilgrim,
Phone: (413) 545-3918                A143B Lederle Graduate Research Center,
Fax:   (413) 545-1249         University of Massachusetts, Amherst, MA 01003
<srivasta@pilgrim.umass.edu> <URL:http://www.pilgrim.umass.edu/%7Esrivasta/>

Reply to: