Re: Bug#147077: Please fix make-kpkg to build packages with proper conflicts
Manoj,
Thank you for your prompt and extensive reply. I have a couple of
questions about some of your observations.
> g) Some people are successfully using built in kernel pcmcia modules,
> along with tools that expect the modules files to live in
> /lib/modules/$(uname -r)/pcmcia/; thus removing the symlinks
> unilaterally is not a good idea either. (I think this is indeed a
> valid scenario)
Some people are successfully using systems with both the built in
kernel pcmcia modules and the stand-alone pcmcia modules installed. (I
have done it myself. It works in all but the most unusual cases.)
Since you are advocating supporting obsolete (possibly broken)
configurations, such as the one you cite above, do you advocate
allowing both sets of modules to be installed at the same time?
> h) I would much rather not go down the path of looking into .config
> file to check for particular modules, make separate image files
> for these modules on the fly, and if these modules have been
> compiled in do other things, special casing each module as
> needed.
Then what is your opinion about the separate
kernel-pcmcia-modules-2.4.18-xxx packages that Herbert has been
producing? He has already implemented one of these "special casing"
scenarios for splitting out the pcmcia modules from the
kernel-image-2.4.18 packages. I think that users will find it
surprising that the official Debian kernel packages are structured
somewhat differently (in that some modules are split into their own
package) than the kernel-image packages that they produce themselves.
Don't you agree?
> a) During compile time, look into $KRC/.config, and take action at
> this point. One should consider that the modules are going to be
> installed with a different kernel-image, ...
No. This (using modules with a different kernel-image) is not at all
supported, nor do I think it should be. If you have ever tried
building the stand-alone PCMCIA modules against more than one kernel and
screwed it up, you should understand why. Each set of pcmcia-modules
is guaranteed to work with only one kernel. If the user wants to try
the modules with another kernel, he is on his own.
> b) The preinst could check for the symlinks before install, and ask
> the users to remove them, or abort install, or whatever. This
> educates the users, and allows the human to take corrective action
> as needed.
How can the preinst remove symlinks that belong to (i.e., are contained
as part of) another package? That is clearly a violation of policy,
UNLESS these "compatibility symlinks" are not contained in the
kernel-image (or kernel-pcmcia-modules) package, but are created by
that package's postinst script.
> Unless there are objections, I'll assign it back to
> pcmcia-source (or tag it won't fix for kernel-package). That is,
> unless people come forth with convincing arguments to change my
> mind.
No objections here. I can implement some sort of hack as a fix. (Why
not? I've already done plenty of work hacking stuff to make way for
these god-awful kernel modules.) I don't know exactly how to proceed
yet, until you provide your opinions to the questions I have raised
above.
- Brian
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: