Re: dns/bind916 builds rust unexpectedly

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.