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

Re: Bug#126856: kernel-package: kernel-image should deal with flavours just like modules packages

reopen 126856
severity 126856 serious

[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

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


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 (!)

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

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: pgpEcKCv4jGOn.pgp
Description: PGP signature

Reply to: