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
/boot/vmlinuz-2.4.22
/boot/System.map-2.4.22
/lib/modules/2.4.22/...
and you have to handle upgrades to either of:
Package: linux-2.4
Version: 2.4.22-2
/boot/vmlinuz-2.4.22
/boot/System.map-2.4.22
/lib/modules/2.4.22/...
or:
Package: linux-2.4
Version: 2.4.23-1
/boot/vmlinuz-2.4.23
/boot/System.map-2.4.23
/lib/modules/2.4.23/...
I'll just assume you can follow that. You have to handle the following
upgrades:
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)
Right?
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
/boot/vmlinuz-2.4.22
/boot/System.map-2.4.22
/lib/modules/2.4.22/...
Package: kernel-image-2.4.22-1-i386
Version: 2.4.22-2
/boot/vmlinuz-2.4.22
/boot/System.map-2.4.22
/lib/modules/2.4.22/...
Package: kernel-image-2.4.23-1-i386
Version: 2.4.23-1
/boot/vmlinuz-2.4.23
/boot/System.map-2.4.23
/lib/modules/2.4.23/...
[ 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
kernel-image-2.4.22-1-i386.
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
that.
> 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.
--
Marcelo
