tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: updating a piece of the running system from build.sh is too hard



At Mon, 1 Mar 2010 17:20:35 +0900, Masao Uebayashi 
<uebayasi%tombi.co.jp@localhost> wrote:
Subject: Re: updating a piece of the running system from build.sh is too        
hard
> 
> Understood, but I'm looking forward more; syspkgs.  If we always create
> packages from the staged (dest)dir and install them via pkg_install(8), we
> can concentrate installation path in single point; we use the same method to
> install NetBSD in sysinst(8), line install, or embedded target image creation.
> This is a huge win.

The problem is that syspkgs don't solve the problem being asked about,
at all, not one bit.

Worse, using syspkgs for this purpose would add huge amounts of
unnecessary overhead -- syspkgs will still have multiple directories
worth of targets in one package.

Besides, this is already basically what one gets from "build.sh sets" --
one can just grab the appropriate file(s) from whatever sets archive(s)
are built and extract them to the target system's root directory.

I've had the following notes in my build.sh wrapper script for quite a
very long time now, basically boiling down to what Greg Troxel finally
came up with as his current working solution too:

# NOTE:
#
# To build and install something direct to / -- i.e. to patch the host system:
#
#       . ./myhelpers.ksh
#       nbmake-$(uname -m) MKUNPRIVED=no install DESTDIR=/
#
# To do this on a system where you don't normally do full builds
# you'll need to do the following to create a working build
# environment before you can build an individual program:
#
#       ./mybuild.sh -L [-u]            # XXX build.sh only does -t


The myhelpers.ksh script really just sets PATH to point to the
appropriate TOOLDIR so that you don't have to remember/type some long
complex pathname to get to nbmake-*.

(the '-L' option to mybuild.sh will first run "build.sh tools", and then
build just libraries using the nbmake-foo wrapper script and the "obj",
"do-distrib-dirs", "includes", and then "do-libs" make targets)


As you can guess this solution has worked very well for me since about
2004 or so, though it has become increasingly rare for me to use this
DESTDIR=/ trick, as most/all of my "production" machines are stable
enough that I rarely have to patch base-os stuff any more.  What I do
instead are whole upgrades by (re)extracting the sets files and
rebooting a new kernel, or even booting from bootable install media and
using systinst's upgrade option.


There are limitations to the DESTDIR=/ installs of course -- if the
build.sh products also include new/different shared libraries, (and you
don't static-link as I usually do), then all kinds of things can go
wrong.  Eg. trying to build something from -current and patch an older
release may not work -- symbols may be missing from the installed
libraries, or worse there may be some more serious incompatibility.

-- 
                                                Greg A. Woods
                                                Planix, Inc.

<woods%planix.com@localhost>       +1 416 218 0099        http://www.planix.com/

Attachment: pgpFDu8nfKaIv.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index