[Bug 264949] lang/gcc11: Needs build time warning for /tmp consumption

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 01 Jul 2022 11:31:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264949

Lorenzo Salvadore <salvadore@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://reviews.freebsd.org
                   |                            |/D35688
           Severity|Affects Only Me             |Affects Some People
             Status|Open                        |In Progress

--- Comment #22 from Lorenzo Salvadore <salvadore@freebsd.org> ---
I have the impression that I am the only one to be worried about package build
servers load, so I would say that at least for now writing a pkg-help is
enough. We can always find a better solution later if needed.

I have created a phabricator review with a pkg-help draft:
https://reviews.freebsd.org/D35688

(In reply to Mark Millard from comment #18)

> And other ports would also be built during those same 8+
> hours: 23 other builders would be available and probably
> be active much of the time.

If all remaining builders are active, it probably means that the builders
making gcc could be used to make something else if compilation was quickier. On
the other hand, if there are some inactive builders, then they are inactive
because they have gcc as dependency and then we have a bottleneck.

(In reply to Matthias Andree from comment #21)

> - should build cluster defaults possibly be refactored to a separate cluster-specific configuration (that will obviously have to be documented and publicly available so we stand a chance of analyzing pkg-fallout mail)

I think it is a good idea, but I don't see it happening: it would make
maintainance and testing more complex for too little gain. Do we have other
cases where default options are good for package build servers but often bad
for users building their own ports? (By often, I mean often enough to have
reports of users failing their compilations. In this case we have this PR and
some more cases on EFNet.)

> - should there be a tuning guide which gets revisited, say, yearly, from configuration data we have, or from polling with users, to decide what the default port settings should look like? Say, "what did people usually buy five or four years ago" which should cover most, and those who run written-off stuff may occasionally tweak.

We have plenty of different ports, each one with their specific particular
cases. I think we can have some general guidelines, as we already have, but I
think choosing the best combination of default options is the maintainer's
responsibility.

-- 
You are receiving this mail because:
You are the assignee for the bug.