On 9/25/23 13:39, George Mitchell wrote:
On 9/25/23 16:29, Patrick M. Hausen wrote:
[...]
really not intending to be the wise guy, but if you have any significant
number of machines to manage and special package requirements,
please by all means run poudriere. It's a marvelous piece of software.
We went that way early 2017 and never looked back.
[...]
I tried it when it was first made available and it caused a crash of
the whole system. No doubt it is much better now, but it's also a
huge heavyweight operation by my standards, and my unapproved method
(update packages when they develop security problems, using partmaster)
works well enough for me. -- George
Poudriere still causes crashes in my experience depending on
hardware, poudriere configuration, and what you tell it to build; I have
to change defaults to use it and then it is fine. With only 32GB of RAM,
if I have it operate the whole build process in RAM
(USE_TMPFS=all>/usr/local/etc/poudriere) then I have to limit myself to
2 build jobs (PARALLEL_JOBS=2, though I specify it on the poudriere
command line) or I 'may' have issues. Within that I can have multiple
jobs per build (ALLOW_MAKE_JOBS=yes>/usr/local/etc/poudriere,
MAKE_JOBS_NUMBER=4>/usr/local/etc/poudriere.d/make.conf) which gets
through each compile job much faster so no one job is as likely to be
running 'alone' holding up other jobs while cores sit idle.
I usually use `/usr/bin/nice -n 18 /usr/sbin/idprio 31 ` at the start
of my poudriere command and move on with my life letting it run in the
background while using the same computer with usually little impact
observed other than 'it takes a while'. On my system, MAKE_JOBS_NUMBER=#
of cpu cores which combined with PARALLEL_JOBS means I should have up to
2 compile tasks per core coming in from poudriere.
I heard synth was a lighter build process/environment compared to
poudriere which wants to reset the build environment to be fresh per
package but never tested it out myself. Switching from portmaster and
portupgrade avoided a lot of nuisance failures as a decent # of ports
'silently' use things outside the ports tree that they are not supposed
to use so should be marked as build isn't compatible with that port
being installed; when a port like avahi (if my memory serves) needs to
be marked incompatible with itself and it is a dependency of many ports,
it meant either downtime during rebuild or software would be flakey if
trying to continue using it while the rebuild of it + dependent software
was rebuilt. Technically software that is accessing local tools and
files dynamically at compile time should all be forced to not do so if
we want any package consistency and software that is incompatible should
be fixed to stop accessing already installed files that it is supposed
to be the one to provide or at least be marked as broken for doing so.
Usually I only found these build failures occasionally when
'incompatibilities' arose between installed version vs what the build
preemptively makes or dynamic dependencies changed what gets installed
leading to untracked files. It hit much worse when I upgraded from i386
to amd64 in place instead of remove+reinstall; many packages were caught
'reaching out' to i386 counterparts that they were not supposed to touch
by the failures that resulted. Unless these issues are actively being
found+fixed, tools like portmaster and portupgrade need manual steps
always called out in UPDATING (which did 'not' call nearly as many of
these as I found) or shouldn't be recommended unless teaching users of
such pitfalls and give them an idea to notice+fix them.
If any porters know of ways to avoid calling local tools and
libraries when the correct ones should only be called form the build
directory I would really appreciate learning. I doubt anyone cares
enough but installing i386 package then trying to locally build the
amd64 port looked like the easiest way I knew of to catch these issues
but would also like knowing a better way (only catches binary
incompatibilities and not the general accessing files that shouldn't be)
and don't know if pkgng would even let me test such a run.
