Re: Bug#147077: Please fix make-kpkg to build packages with proper conflicts
>>"Brian" == Brian Mays <brian@debian.org> writes:
Brian> Some people are successfully using systems with both the built
Brian> in kernel pcmcia modules and the stand-alone pcmcia modules
Brian> installed. (I have done it myself. It works in all but the
Brian> most unusual cases.) Since you are advocating supporting
Brian> obsolete (possibly broken) configurations, such as the one you
Brian> cite above, do you advocate allowing both sets of modules to
Brian> be installed at the same time?
I would defer to your experience here; I am not personally
using the implementation cited above, but one person who is wrote me
in private email. I would not be against stating the setup that needs
the symlink when using the builtin kernel pcmcia modules is obsolete.
However, since we support people downloading the kernel
sources from kernel.org directly, whether the symlinks are good or
not is moot; upstream still has these links, and we must deal with
them.
I am more concerned, though, about having modules with the
same name in different part of the lib/modules/$(uname -r) hierarchy,
perhaps because I do not know what the ordering of the search paths
are. Personally, I would not recommend installing both sets of
modules besides each other; I would say that for most novices, this
is likely to be something that was unintended.
Given that, I would not prohibit contemporaneous installation
of both sets of pcmcia modules, but I would strongly advocate a
diagnostic being issued, and perhaps even ask the person installing
if this is what the intend.
>> 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.
Brian> Then what is your opinion about the separate
Brian> kernel-pcmcia-modules-2.4.18-xxx packages that Herbert has
Brian> been producing? He has already implemented one of these
Brian> "special casing" scenarios for splitting out the pcmcia
Brian> modules from the kernel-image-2.4.18 packages.
I am not sure if my opinion has much meaning. I certainly am
not a fan of the gazillion kernel image packages for the same
architecture, complete with the corresponding header, doc, and source
binary packages; I have never been convinced of the ROI (if I may
stretch the term) or compiling for k6/k7/i386/i586/i686/i686smp
separately justifies the utility for the users. But, as author of
kernel-package, I may be biased about the simplicity of and rationale
for everyone compiling their own, tailor made, kernel.
I am similarly not a fan of splitting out the modules from
the kernel image packages, but it all boils down to whether one
should expect users to do kernel compiles.
Brian> I think that users will find it surprising that the official
Brian> Debian kernel packages are structured somewhat differently (in
Brian> that some modules are split into their own package) than the
Brian> kernel-image packages that they produce themselves. Don't you
Brian> agree?
I do think that this is not a good scenario, but this seems to
be a fait accompli.
>> 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.
Brian> How can the preinst remove symlinks that belong to (i.e., are
Brian> contained as part of) another package? That is clearly a
Brian> violation of policy, UNLESS these "compatibility symlinks" are
Brian> not contained in the kernel-image (or kernel-pcmcia-modules)
Brian> package, but are created by that package's postinst script.
No, I said "Ask the users to remove the symlinks". So, go
ahead, remove the symlinks, come back, and hit enter while I wait and
whistle at the flowers. The sysadmin can remove any symlink he/she
wants, it is their machine.
If not, you can just abort at that point; the human can decide
to use the kernel pcmcia modules, recompile a kenrel and pcmcia
modules (built in or stand alone), remove the symlinks and retry, or
whatever. The human gets to decide, we just provide the tools that
they can use.
manoj
--
Sometimes you get an almost irresistible urge to go on living.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: