On Sat, May 10 2014, Adam Borowski wrote: > On Tue, May 06, 2014 at 07:30:58AM -0700, Manoj Srivastava wrote: >> On Tue, May 06 2014, Adam Borowski wrote: >> >> > On Mon, May 05, 2014 at 02:07:30AM -0700, Manoj Srivastava wrote: >> >> On Sat, Mar 16 2013, Adam Borowski wrote: >> >> >> >> > ls -al /lib/modules/3.8.2-x32 >> >> > lrwxrwxrwx 1 root root 36 Sep 27 04:09 build -> >> >> > /home/kilobyte/tmp/kernel/linux-source-3.8 >> >> > lrwxrwxrwx 1 root root 37 Sep 27 04:09 source -> >> >> > /home/kilobyte/tmp/kernel/linux-source-3.8 >> >> If this is not your build machine, are the symlinks dangling? >> The image package postinst is supposed to remove them. > > On machines other than the build one, the "source" symlink has been removed, > the "build" one correctly goes to /usr/src/linux-headers-3.14.3-x32
OK, so that is working correctly, am I right?
>> If it is your build machine, then this is the current behaviour
>> to leave the links pointing to your build directory. This can of course
>> be overridden by adding your own postint file to the postinst.d
>> drectory.
> On the build machine, both "source" and "build" point to the directory the
> kernel happened to be built in, in my case in a directory owned by an user
> other than root.
This is what I would expect, yes
> This leads to failures:
> * if I delete the unpacked sources, dkms fails to find installed
> linux-headers-XXX. This is likely when using packaged linux-source which
> embeds its version number in its top directory's name.
Perhaps it prefers the source link, which is now dangling? I
suppose is you delete the source directory where the build is you
currently need to also delete the source link. Yuck. I tend to keep a
shallow clone source directories of active kernels around, but that is
not something that can be reasonably required.
> * if I checkout some other version, dkms will build against the currently
> unpacked tree rather than installed linux-headers-XXX. This is likely
> when building from git.
I am guessing the source link continues to point to the git
tree.
What behaviour would youlike to see on the machine where you
build sources? not install the links pointing to the current build
tree? I personally find that convenient, since I just build and install
image packages, and leave sources lying aroung.
Perhaps another kernel-img.conf option to just delete the
symlinks? We already have:
--8<---------------cut here---------------start------------->8---
relink_build_link
This option manipulates the build link created by recent
kernels. If the link is a dangling link, and if a the
corresponding kernel headers appear to have been installed on
the system, a new symlink shall be created to point to them. The
default is to relink the build link (YES).
force_build_link
This option manipulates the build link created by recent
kernels. If the link is a dangling link, a new symlink shall be
created to point to kernel headers data in /usr/src, whether
they have been installed or not. The default is unset, we don't
create potentially dangling symlinks by default.
relink_src_link
This option manipulates the source link created by recent
kernels. If the link is a dangling link it is deleted at install
time. The default is to relink (delete) the source link (YES).
--8<---------------cut here---------------end--------------->8---
manoj
--
I never made a mistake in my life. I thought I did once, but I was
wrong. Lucy Van Pelt
Manoj Srivastava <sriva...@acm.org> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
signature.asc
Description: PGP signature
