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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Tue, Nov 11, 2003 at 12:21:32PM +0100, Robert Millan wrote:

 > or who pretend the dessign of my package is broken in a way that I
 > can't solve such trivial bugs.

 Look, you see whatever you want to see, but you are still missing the
 forest for the trees.  When I mentioned System.map this was an
 _example_, get it?

 The fundamental problem with your package is that you have:

 Package: linux-2.4
 Version: 2.4.22-1


 and you have to handle upgrades to either of:

 Package: linux-2.4
 Version: 2.4.22-2



 Package: linux-2.4
 Version: 2.4.23-1


 I'll just assume you can follow that.  You have to handle the following

    a) linux-2.4 (2.4.22-1) -> linux-2.4 (2.4.22-2)
    b) linux-2.4 (2.4.22-1) -> linux-2.4 (2.4.23-1)


 Assuming the user is running 2.4.22, in case a) you are replacing the
 _running_ kernel image.  In particular, the System.map file _on disk_
 does not correspond to the running kernel image anymore.  Stuff like
 top, ps, klogd and ksymoops won't work properly (if you have to ask why
 or why this is important, just go RTFM).  The _modules_ on disk don't
 correspond to the loaded modules, and it's possible that they don't
 even load anymore.  In this situation the most sensible thing to do is
 reboot.  It's a PITA but it can't be worked around without changing the
 kernel's idea of its own version (or better said, without ensuring
 somehow that 2.4.22-1 and 2.4.22-2 exist at the same time on the
 machine, which we don't support, this is not rpm)

 Still with me?

 In b) you _still_ have this problem because dpkg is going to remove
 linux-2.4 (2.4.22-1)'s files and put linux-2.4 (2.4.23-1)'s in place.

 Still there?

 By this point the problem should be self evident, but since we've
 gotten to the point where I have to spell this out for you, I'll just
 keep explaining.

 The situation is now worse: there are _no traces_ of 2.4.22 left on the
 system.  Loading modules will just fail, because the modules are _not_
 there.  System.map-2.4.22 is gone for good, so any sort of debugging at
 this level will be just harder if not impossible (if you like decoding
 kernel addresses in your head for breakfast that's fine, but I know
 plenty of people who don't).  The user _has_ to reboot into a kernel
 that he's not even sure _works_.  If you claim that _every_ time you
 have upgraded a kernel it's worked right out of the box, I'm going to
 ask the Smithsonian to put you on exhibition.  I'm sure it will be more
 successful than that lame Star Wars thing.

 Still following?

 With the current kernel-image-2.4.22-1-i386 packages you have:

 Package: kernel-image-2.4.22-1-i386
 Version: 2.4.22-1


 Package: kernel-image-2.4.22-1-i386
 Version: 2.4.22-2


 Package: kernel-image-2.4.23-1-i386
 Version: 2.4.23-1


 [ Here I'll just state that I don't know if the -1- bit in the package
   name modifies the kernel version in any way because it's been ages
   since the last time I used the official debian kernel images. ]

 With this we have:

    c) kernel-image-2.4.22-1-i386 2.4.22-1 -> 2.4.22-2

 and that's it.  There's no 2.4.22-1 to 2.4.23-1 upgrade path because
 that _is not_ an upgrade with this scheme.  That's a feature.
 Installing kernel-image-2.4.23-1-i386 doesn't nuke

 Is that clear with you?

 Since the only upgrade to handle is 2.4.22-1 -> 2.4.22-2 we still have
 the same problem that I described before with System.map and the
 modules, but _only_ that problem.  We don't have the things gone for
 good problem and we don't have the very ugly "is this thing going to
 work at all?" problem.

 Do you see the forest now?

 > > How do you propose to do that without changing the package name,
 > > and without leaving old System.map junk around for eternity? I
 > > don't see how it can be possible.
 > I don't like turning this ITP into a technical discussion to prove
 > either my dessign is consistent or I'm capable as a maintainer.

 You are proposing to package a fundamental piece of software in a way
 that's prone to _break_.  Since this ITP is _only_ about repackaging
 something we already provide, the discussion about the design
 decisions is more than justified.

 > However I'll respond to your question this time:

 Oh, thanks, you answer questions for a change.

 >   Place the package files in /usr/lib, and copy them conditionaly
 >   (debconf) into /boot. The debconf question would properly explain
 >   that if per chooses to update it, then the system must be rebooted
 >   promptly.

 You mean you want to have unmanaged files under /usr/lib?  What's the
 point of providing a binary debian package then?  Do notice that you
 have to hand-manage the kernel image, System.map, the modules, some
 include files and the configuration files (that is if you want to do it
 right).  Not actually a small number of junk.

 See the underlined question from Colin above, you forgot to answer

 > I don't feel it necessary. But this is not the first trivial
 > maintainer issue I'm being pointed at in this ITP, and I'm getting
 > the impression that some people are doing it deliberately.

 Yes, Robert, join #we-r-out-to-get-robert (password is
 debian-can't-handle-upgrades) and have some fun with us.  Don't mind
 the black choppers parked at the door.


Reply to: