I'm finally getting around to doing 1.12 upgrades, and have setup a
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested
However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires
only the userland, appropriate headers and correct 'uname' output - so:
it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or
maintaining a separate physical host
I did a quick scan of the tree to see what this would take, and, high
level, it seems like only the following changes would need to be made:
- update struct jail to add a 'osrelease' string
(implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
(if possible - didn't get this far in the research yet)
could be less of a problem for builds, as I think most things use
uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something
in the build I'm not familiar with?
also,
is the so-called 'stupid hackery' in sys_uname needed still?
Before I start any coding, does this:
- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on - for example setting up automated bulks w/various combinations
of pkgsrc and releases, etc.
Cheers,
- Chris
