Re: CVS commit: src

[Havard Eidnes <he%NetBSD.org@localhost>]

> > Module Name:        src
> > Committed By:       ad
> > Date:               Tue May 20 19:01:11 UTC 2008
> >
> > Modified Files:
> >     src/distrib/sets: sets.subr
> >     src/distrib/sets/lists/base: lkm.mi md.i386 mi
> >     src/etc/mtree: NetBSD.dist
> >     src/share/mk: bsd.kmodule.mk bsd.own.mk
> > 
> > Log Message:
> > Install kernel modules into the proper locations, taking machine and
> > kernel version into account.
>
> A couple of comments on this:
>
> 1) This does not appear to have been tested with a full release
>    build.  The reason I beleive that is that all my local builds
>    now bomb out when processing the set lists because only the
>    /stand/ and /stand/<machine>/<os-version>/<module>/
>    directories are defined in the set lists, and mtree complains
>    bitterly because /stand/<machine>/ isn't defined anywhere:
>
> checkflist ===> distrib/sets
> nbmtree: ./stand/algor: No such file or directory
> nbmtree: failed at line 27157 of the specification
>
> *** Failed target:  /u/build/HEAD/dest/algor/METALOG.sanitised
> *** Failed command: ( cat /u/build/HEAD/src/etc/mtree/NetBSD.dist ; echo 
> '/unset all' ; cat /u/build/HEAD/dest/algor/METALOG ) | 
> /u/build/HEAD/tools/algor/bin/nbmtree -C -k all -N /u/build/HEAD/src/etc > 
> /u/build/HEAD/dest/algor/METALOG.new && ( rm -f 
> /u/build/HEAD/dest/algor/METALOG ; mv /u/build/HEAD/dest/algor/METALOG.new 
> /u/build/HEAD/dest/algor/METALOG )
> *** Error code 1

This is caused by me doing an unprivileged build, and a sub-directory
being mentione in METALOG before all its parent directories are
mentioned.

This is fixed (or worked around?) by this patch:

Index: bsd.kmodule.mk
===================================================================
RCS file: /u/nb/src/share/mk/bsd.kmodule.mk,v
retrieving revision 1.8
diff -u -p -r1.8 bsd.kmodule.mk
--- bsd.kmodule.mk      21 May 2008 03:48:42 -0000      1.8
+++ bsd.kmodule.mk      21 May 2008 13:07:21 -0000
@@ -49,6 +49,10 @@ _OSRELEASE!= ${HOST_SH} $S/conf/osreleas
 KMODULEDIR=    ${DESTDIR}/stand/${MACHINE}/${_OSRELEASE}/modules/${KMOD}
 .endif
 _PROG:=                ${KMODULEDIR}/${PROG} # installed path
+# Ensure these are recorded properly in METALOG on unprived installes:
+_INST_DIRS=    ${DESTDIR}/stand/${MACHINE}
+_INST_DIRS+=   ${DESTDIR}/stand/${MACHINE}/${_OSRELEASE}
+_INST_DIRS+=   ${DESTDIR}/stand/${MACHINE}/${_OSRELEASE}/modules
 
 .if ${MKUPDATE} == "no"
 ${_PROG}! ${PROG}                                      # install rule
@@ -62,6 +66,9 @@ ${_PROG}:     .MADE                                   # no bui
ld at instal
 .endif
 .endif
        ${_MKTARGET_INSTALL}
+       for d in ${_INST_DIRS}; do \
+               ${INSTALL_DIR} $$d; \
+       done
        ${INSTALL_DIR} ${KMODULEDIR}
        ${INSTALL_FILE} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \
                ${.ALLSRC} ${.TARGET}

If you're already in the "build still breaks" mode, you also need
to remove $DESTDIR/stand/*/*/modules, to have the realinstall
target executed, and possibly $DESTDIR/METALOG may also need
surgery (removal of the earlier entries).

This reveals another set list problem, though:

=======  4 extra files in DESTDIR  =========
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
------------------------------------------
./kernel
./kernel/modules
./kernel/modules/miniroot
./kernel/modules/miniroot/miniroot.kmod
=========  end of 4 extra files  ===========

which goes back to my earlier comment which said "/stand should not be
the target install directory for kernel modules".

Has the implications of this new "automatically exapand slowly changing
variables in set lists" been sufficiently thought through, particularly
what it means for unprivileged UPDATE builds?  If I understand
correctly, such builds will accumulate entries in both DESTDIR and in
METALOG for old kernel modules.  (I was worried that this would create
yet another "build bombs out on version bump" issue, but on second
thought I think that won't be the case.)

Regards,

- Håvard