reopen 126856
severity 126856 serious
thanks
[cc'ing to debian-devel for comments.]
[please refer to bug 126856 for background info.]
also sprach Manoj Srivastava <srivasta@debian.org> [2002.01.06.1016 +0100]:
> Wrong. Read the documentation on the Flavours before using
> it. This is the reason that Flavours are deprecated, incidentally.
okay, i did read /usr/share/doc/kernel-package/Flavours.gz, but it
really just didn't solve my problem.
the reason that i am objecting to closing this bug is because i have
official debian packages here to compile my kernels and modules, and
what i get out is *broken*. i don't care whether flavours are (going to
be) deprecated, that feature exists with the release of kernel-package
that i have, and thus i should be able to use it. i am thus reopening
the bug as well as raising its severity, not because i want to "catch
attention" or anything, but because kernel-package violates debian
policy!
when i compile the kernel as flavour "fishbowl" and the
kernel-image*.deb package places its modules into /lib/modules/2.4.17,
while proper modules packages like alsa-driver or pcmcia-cs put their
modules in 2.4.17+fishbowl, then there is a problem. without manual
interaction, you won't get the new kernel to see the modules of the
modules package. and that i consider a serious bug!
moreover, the packages compiled with kernel-package actually end up
leaving files on a system that are not registered as belonging to any
packages. these are orphan files, and even though i can't find the
section of the policy manual that addresses this, it seems fairly
obvious that this shouldn't happen. consider a custom kernel
kernel-image-2.4.17+fishbowl and a corresponding package
pcmcia-modules-2.4.17+fishbowl. when the pcmcia package is updated and
apt-get installs the new version on the machine, it not only doesn't
place the modules under /lib/modules/2.4.17 where the kernel modules
reside, it creates a directory for the format
/lib/modules/2.4.17+fishbowl_[0-9]{4}. for instance, this is after
updating the kernel and pcmcia-modules package a couple of times:
fishbowl:~> ls -1 /lib/modules
2.2.20-compact_2169
2.4.17
2.4.17+fishbowl_1344
2.4.17+fishbowl_2634
2.4.17+fishbowl_5736
2.4.17+fishbowl_7652
*but*:
fishbowl:~> dpkg -S /lib/modules/*
kernel-image-2.4.17+fishbowl: /lib/modules/2.4.17
fishbowl:~> dpkg -l | grep "kernel-image\|pcmcia-modules"
ii kernel-image-2 20020104.1146 Linux kernel binary image 2.4.17+fis
ii kernel-image-2 20010822.0048 Linux kernel binary image 2.4.5+fish
ii pcmcia-modules 3.1.29-4+20020 PCMCIA Modules for Linux 2.4.17+fish
first of al, 2.2.20-compact wasn't even compiled by me, but it still
left a directory in /lib/modules that wasn't removed when i purged (!)
kernel-image-2.2.20-compact.
then, not even the installed pcmcia-modules package knows about
2.4.17+fishbowl_7652 in /lib/modules, which it left there. the three
predecessor versions of pcmcia-modules had the same problem and left
orphan files.
so this is pretty much two bugs, the first one has major effects on
usability, the second violates the policy. i don't think this bug is
closed yet.
any comments welcome. thanks.
and maybe someone can suggest an alternative to flavours. i have about
27 systems for which i have kernel-images, using the flavour to specify
the machine name. this works beautifully. without the flavour, i would
not have the possibility to update one machine's kernel and install it
via apt from my own apt-compatible server. i need to be able to do this.
scp'ing and dpkg -i are not options, apt-get upgrade must take care of
this.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
"if beethoven's seventh symphony
is not by some means abridged,
it will soon fall into disuse."
-- philip hale, boston music critic, 1837
Attachment:
pgpIvKJDJkP07.pgp
Description: PGP signature