[Bug 264949] lang/gcc11: Needs build time warning for /tmp consumption
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.