[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: versioned files in DESTDIR breaking build
> >> ======= 16 extra files in DESTDIR =========
> >> Files in DESTDIR but missing from flist.
> >> File is obsolete or flist is out of date ?
> >> ------------------------------------------
> >> ./stand/i386/4.99.66
> >> ./stand/i386/4.99.66/modules
> >> ./stand/i386/4.99.66/modules/cd9660
> >> ./stand/i386/4.99.66/modules/cd9660/cd9660.kmod
> >> [more]
> >> ========= end of 16 extra files ===========
> > You get this every time NetBSD-current bumps the verison number!
> > When we move to 4.99.68, you'll have an old 4.99.67 directory that
> > will need cleaning.
> Exactly, so I'm suggesting that the build procedure should be changed so
> this doesn't happen. Presumably all these files are getting added to
> the obsolete sets list so poinstall fix can remove them; perhaps that
> should be run on destdir.
The old modules are not fixed up by postinstall, and they
probably should not be either...
The reason is that build.sh may be used with -E or -D /, i.e.
installing into the currently running system. The build.sh
script has no idea whether you later want to revert back to
running the kernel from the previous release number. If
postinstall were to clean out the modules when the version number
is bumped, no compatible kernel modules would remain if you
wanted to downgrade the kernel.
On the other hand... When you install the fresh -current
user-land into /, you have pretty much cut yourself off from
being able to run an older kernel, since there's no guarantee
that a new user-land will be able to run with the old kernel. So
maybe the old kernel modules should be removed anyway, and what I
said above was wrong, and this ought to be handled better. :-)
Main Index |
Thread Index |