Re: Bug#249978: kernel-package: Could we have kernel-image packages check for anything but build on install?
reassign 249978 kernel
clone 226779 -1
reassign -1 kernel
merge -1 249978
thanks
On Mon, 13 Sep 2004 09:22:25 -0400, Len Sorensen <lennartsorensen@ruggedcom.com> said:
> Perhaps if instead of checking if /lib/modules/version exists, check
> if /lib/modules/version exists and contains anything other than the
> build symlink. Having a warning message just because kernel-headers
> is aphabetically before kernel-image and creates the dir first with
> one symlink in it, is really confusing many newer users.
That won't help, since then dpkg would fail when it finds that
two packages own /lib/modules/$version/build. The problem lies in
kernel-headers including this link all of a sudden -- it should not,
since it is owned by kernel-image packages.
There is more discussion in 226779, where Herbert provides the
rationale for kernel-header packages suddenly deciding to also
include this symlink, despite that file already being present in
kernel-image packages. Policy says that if kernel-header packages do
so, they must conflict with kernel-image packages -- which is clearly
not desirable.
One solution, which I proposed, was that kernel-image
packages could, on installation, relink a dangling
/lib/modules/$version/build symlink to an existing kernel-headers
directory, if we could have some kind of consensus on what would be a
valid name.
This has a couple of drawbacks -- you still need a
kernel-image package to have the build symlink, and Herbert wanted
the headers package to be standalone.
One solution would be to never ship a build link, but to ship
build.image, build.headers links; and have the postinst cp -P the
symlink if none existed, and the source symlink is not dangling.
This would need changing the kernel packages rules file; to
rename the symlink for the image; to ship the renamed symlink for the
headers, and to change the postinsts to manipulate the symbolic link
and cp/mv them if desired. I wonder if this is too close to release
to make this kind of a change; but the current practice of shipping
the conflicting build file in the headers packages _without_
conflicting with the image packages must stop.
manoj
--
You shouldn't have to pay for your love with your bones and your
flesh. Pat Benatar, "Hell is for Children"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: