matthew at FreeBSD.org
Mon Sep 9 22:46:09 UTC 2019
On 09/09/2019 20:58, Paul Macdonald via freebsd-questions wrote:
> After many years of procrastination, i finally have a poudriere system
That's some expert level procrastination there...
> It wasn't actually that hard to do, and i already wonder why i didn't do
> it ages ago.
> I'd be grateful if anyone in the group had any tips to share that i can
> benefit from, before learning the hard way?
You're using poudriere to build your own package repo, rather than eg.
as a testing stage in port maintenance?
Well: tips. Try these for size.
* Create your ports tree based on your pre-existing checked out version
of the ports in /usr/ports:
% poudriere ports -l
PORTSTREE METHOD TIMESTAMP PATH
default svn 2019-09-08 11:26:04 /usr/ports
(You don't have to use svn as the method -- any available method will work)
* Then create a link from /usr/local/etc/poudriere.d like so:
% ls -l /usr/local/etc/poudriere.d/options
lrwxr-xr-x 1 root wheel 13 Dec 24 2012
/usr/local/etc/poudriere.d/options@ -> /var/db/ports
This means that instead of using `poudriere options` to set the build
options for your local ports, you can just change to the appropriate
directory under /usr/ports and `make config`
* If you're building ports for a number of machines of varying versions,
you'll need a poudriere jail for each major version of FreeBSD your
machines are running, and that jail should be running a release version
as old as (or older) than the earliest version you have on each major
* Contrary-wise, the version of the OS you run on your poudriere build
box must be newer than (or at least as new as) the most modern poudriere
jail you have.
So a recent 12-STABLE machine could have poudriere jails for
12.0-RELEASE and 11.2-RELEASE, but not HEAD. Packages built on an 11.2
jail will work just fine on an 11.3 system, but not necessarily the
converse: packages built in an 11.3 jail may not work properly on an
* Of course, if you're building packages for a single machine, then just
make the poudriere jail the same version as your machine.
* Use ccache.
* ccache defaults to a 5GB maximum cache size. Depending on how many
packages you're building this may not be enough. Keep an eye on your
ccache stats over a few weeks of package building to see if enlarging
the cache would be useful.
* Use CHECK_CHANGED_OPTIONS=verbose in poudriere.conf
* Use CHECK_CHANGED_DEPS=yes in poudriere.conf
* Given the above, you will rarely need to do a 'poudriere bulk -c' --
the vast majority of the time poudriere will upgrade just the packages
it needs to with an incremental 'poudriere bulk'. Even if there are big
changes like the recent switch of the default version of python from 2.7
to 3.6. You may end up with some older (eg. python27) packages still in
your repo, but that's generally not a problem.
* One thing that will always trigger a complete rebuild of all packages
(effectively a bulk -c) is applying any updates to the poudriere jail,
even if those are eg. kernel security patches (which are irrelevant for
jails). You don't need to be religious about patching your poudriere
jails since they aren't an exposed attack surface. Unless, that is, the
security patches apply to system libraries /and/ you are building
software with static linkage.
* Use ATOMIC_PACKAGE_REPOSITORY=yes and COMMIT_PACKAGES_ON_FAILURE=yes
so that you can still benefit from all the packages that succeeded in
building even if some of them did fail.
* Even if your poudriere jail is several patch-levels older than it
might be, the ability to keep all your installed packages up to date
easily will still pay dividends in helping you keep all your servers
* If you aren't building many (ie. less than about a thousand) packages,
I find that enabling the display of packages still to be built in the
poudriere web interface (HTML_TRACK_REMAINING=yes in poudriere.conf) is
useful, and with the relatively small number of packages it doesn't have
a significant effect on performance.
* Watch out for packages that have BUILD/RUN depends on llvm*, openjdk
or a number of other monster packages. Those can easily take as long to
build as all of your other packages put together, and may suck up great
gobs of system resources if you try and make them build quicker by
allowing them to use multiple make jobs. Just be patient -- they'll get
there in the end.
(*) As a general rule. It could well be that the two specific versions
mentioned /don't/ have any such problem -- I haven't tested so I can't
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 963 bytes
Desc: OpenPGP digital signature
More information about the freebsd-questions