Re: Bug#147077: Please fix make-kpkg to build packages with proper conflicts
[ A copy is being sent to debian-devel, since this topic was raised
there, before the bug was forwarded to kernenl-package. This is
written with the kernel-package author hat on]
>>"Brian" == Brian Mays <brian@debian.org> writes:
Brian> Please look into fixing make-kpkg to avoid building packages
Brian> that have file conflicts such as those described in this bug
Brian> report. As indicated in my last message in this report, the
Brian> ideal fix would yield kernel-image packages that conflict with
Brian> the corresponding pcmcia-modules package when PCMCIA support
Brian> is built into the kernel and yield a separate package of
Brian> kernel pcmcia modules that conflicts with the corresponding
Brian> pcmcia-modules package when PCMCIA support is built as
Brian> modules.
Brian> I'm afraid you shall receive little help from Herbert Xu for this
Brian> one. Apparently, there is never anything wrong with his packages, and
Brian> problems are always somebody else's fault.
Brian> Thank you for looking into this. If you need any help,
Brian> information, or advice please let me know.
I have now reviewed the arguments in the bug report, and have
discussed with people on IRC, trying to come up with a solution.
A number of observations first
a) kernel-package is agnostic of the contents of the kernel images and
modules, and agnostic to the contents of the .config file. This
allows us to use the same kernel-package to compile kernels from
2.0.X to 2.5.X series, despite the changes that have been
occurring. It would even work with the proposed new kernel build
mechanisms, with perhaps a few tweaks to improve efficiency.
b) It is not good to have special case code dependent on the contents
of the config file, and on the version of the kernel, and
information relevant to stand alone modules, since then
kernel-package would have to track all that to ensure correctness
of the hard coded special cases.
c) Adding static dependency relationships is relatively
striaght forward, though deprecated (due to the effort of keeping
track of the correctness of these dependencies). Right now, one
can import a Sid kernel-package into potato, and were it not for
dpkg static dependencies, it would work on Hamm as well.
d) A static dependency, however, is not good enough, it needs to add
a conflict _iff_ the config file shows that some modules were
compiled. Merely looking at package names and versions is not
going to be good enough.
e) Arguably, the solution should be affected in the packages that
need it, anmely, the image and pcmcia packages, and not in tools
higher up the chain.
f) Fixing this in official kernel source packages is an imperfect
solution, since it does not help the people who compile the kerel
sources from kernel.org directly. Since we do not control that
code, we need a solution that would cover more than just consumers
of debian packaged kernel sources.
g) Some people are succesfully 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)
h) I would much rather not go down the path of looking into .config
file to check for partuicular modules, make spearate image files
for these modules on the fly, and if hese modules have been
compiled in do other things, special casing each module as
needed.
i) Also, kernel-package by itself is also not the solution, since we
explicitly allow for people to compile their own kernels from
sources, and the underlying problem of having two sets of modules
for the same device is not going to be addressed by just hacking
some of the kernels that Debian users use.
The problem is two fold: the symptom is a file conflict while
installing pcmcia-modules since a symlink exists in the ekrnel image;
the underlying problem is one of duplicate modules in different paths
of the module tree.
Now, this can be addressed fully within pcmcia-modules, and
needs to be, indeed, since debian users do not have to use debian
packaged kernel sources, or even debian kernel-package packaged
images. pcmcia modules can
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, but then, mixing and
matching kernel modules and images is fraught with problems to
start with. The action taken can be any of abort, ask for
confirmation, add special preinst scripts, etc
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.
This is a far more targeted, surgical correction of the
problem.
Unless there are objections, I'll assign it back to
pcmcia-source (or tag it wonhtfix for kernel-package). That is,
unless people come forth with convincing arguments to change my
mind.
manoj
--
There are no emotional victims, only volunteers.
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: