Sharing compiled builds between multiple 12-CURRENT boxes.

[blubee blubeeme]

On Sun, Aug 19, 2018 at 6:30 PM O. Hartmann <ohartmann at walstatt.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Sun, 19 Aug 2018 00:34:20 +0200
> Dhananjay Balan <mail at dbalan.in> schrieb:
>
> > Hi,
> >
> > I run 12-CURRENT on few machines, some more powerful that other (all
> > of them x86_64, march varies).
> >
> > Is there is a way to avoid building CURRENT on all machines? Rather
> > than building everywhere, can I just build it on the big server that I
> > have and copy and update my laptop?
> >
> > -
> > Dhananjay Balan
> [...]
>
> Yes, you can.
> We do this via a custom build and creating packages as this is introduced
> at
>
> https://wiki.freebsd.org/PkgBase
>
> But beware! As many others have already stated, take care about to use the
> least common
> denominator of achitectural specifications amongst your pools! This means
> to not use any
> kind of optimizations for a specific CPU type for pkg-base distributed
> builds!
>
> Because we build the local OS for fast/server machines always(!) with
> optimisations, the
> pkg-base builds are done in a separate way - which is very easy if you've
> once understood
> the really neat and great build framework of FreeBSD's!
>
> Instead of building the traditional (probably optimised) system from
> /usr/src
> and /usr/obj, now you've to consider a separate path like
> /pool/sources/CURRENT/src (our
> way, since we also try to build packages and object trees for 11.X), then
> setup a small
> build script that essentially sets
>
> MAKEOBJDIRPREFIX
> KERNCONFDIR
> KERNCONF
>
> and especially
>
> __MAKE_CONF
> SRCCONF
> SRC_ENV_CONF
>
> if you use usually optimisations for the native target build on the
> building host and
> more generic binaries for the Intel x86 crap for redistribution.
>
> Doing so, we also perform builds for some ARM64 based experimental boxes.
>
> The next step is then up to you how to distribute. We copy all the pkg
> stuff coming out
> of the build cycle to a folder which is accessible by pkg via HTTP(S) - so
> www/apache24
> is our platform to redistribute the binaries over the network and even to
> remote sites
> (beware of the security implications!). You also can distribute the
> obj-folder (/usr/obj,
> or, if using another approach, like /pool/sources/CURRENT/obj) via NFS.
>
> Once you've understood the (easy to learn) concept of building the source
> tree, creating
> the packages for pkg-base and having dealt with the more labor for the
> setting of a
> distribution server, you can use the most potent server/box on you network
> for building
> dedicated distributions
>
> Even a "Release" build is possible as long as there are not pitfalls like
> they occured
> during the transition from 11.X to more 12-CURRENT spcific development
> (i.e. LINT).
>
> If you use pkg-base as mentioned above, be aware to setup a proper
> pkg.conf file as
> introduced on the Wiki and please be also aware of the fact, that there is
> at the moment
> no sharp separation between pkg-base and oridnary pkg for packages - so
> take the
> warinig serious, that pkg delete -a will not only kill all packages, it
> also will kill
> all packages installed for the base system!
>
> Once installed you'll see how fast compared to source build the pkg-base
> installation
> is (although I still prefer source build, optimised builds ...).
>
> And by the way: depending on the sophistication of your build script for
> dedicated
> tree builds as mentioned, via manipulations of __MAKE_CONF, SRCCONF you're
> able to also
> build optimised binary trees for different CPU types, but you have to deal
> yourself
> with the fact that you've to put the binaries into a proper place and then
> delegate the
> URI in pkg.conf to the correct branch of your tree. The ABI environmental
> variable
> doesn't take care of the "set" you may have used to optimise. But this is
> something
> you're able to deal with easily yourself after having setup your basic
> build
> environment.
>
> Regards,
>
> oh
>
> - --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -----BEGIN PGP SIGNATURE-----
>
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lGDwAKCRDS528fyFhY
> lMBeAf4nVIFEAgegbZyKDZvTQQD/9Q8mN+IY8aJ7Fzza23KgWQsM3ZP59Orh0mi2
> PA94ywn5hOjfTgzdYcp1lq3MCE84AgCBGAWAMTag87ru89JHm75NLsgDvEjPpYgG
> 9hW1Vrdoj9EeiR2HTv2ncTc/AkFPNhdyhe+EJqUg01rtAd9sdmdM
> =/rzO
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

I would say setup a poudriere build bot on your most powerful machine to
build and test all the applications and tools that your weaker machines
need, then setup a custom pkg repo so once poudriere builds all the ports
and create packages from them.

Then you use the custom pkg url to update your other machines.
Quick primer on poudriere:
https://www.freebsd.org/doc/handbook/ports-poudriere.html

Digital Ocean did a write up on exactly what you're requesting here:
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-poudriere-build-system-to-create-packages-for-your-freebsd-servers

Best,
Owen