Re: policy proposal: updating packages with many dependencies

[Jonathan Perkin <jperkin%pkgsrc.org@localhost>]

* On 2025-03-19 at 15:03 GMT, Greg Troxel wrote:

> Thomas Klausner <wiz%netbsd.org@localhost> writes:
>
> > On Tue, Mar 18, 2025 at 09:23:09PM +0100, Roland Illig wrote:
> > > Am 18.03.2025 um 20:50 schrieb David Brownlee:
> > > > If I could suggest anything extra on top it would be an automatic
> > > > warning from pkglint on the relevant base packages :)
> > >
> > > My preferred way would be to mark these base packages by setting a
> > > special variable (similar to META_PACKAGE). This way, pkglint doesn't
> > > need a hard-coded list of package paths on which to warn.
> >
> > Let's paint a shed: What should we call the variable?
>
> I'll bite on painting.
>
>
> > UPDATES_REQUIRE_REVIEW?
>
> POLICY_UPDATES_REQUIRE_REVIEW
>
> so we have a faux namespace that all variables about process start with
> POLICY_.

As a connoisseur of short variable names which also help to keep 
indentation to a sensible length, I'd also recommend making it a 
variable that accepts a list of requirements.

It would be worth, for example, separating out packages that have many 
dependencies and have a history of breaking APIs with those that have 
many dependencies but for which an update would still be painful.

For example, people are suggesting that cmake should not be included in 
this list.  One of the reasons I'm currently having to build packages 
from a fork is because my bulk builds can't keep up with the churn that 
essentially means every build needs to start again from scratch.

By my count between 2024-02-01 and 2025-01-29 cmake was updated 21 
times, not including minor revision bumps.  Every time this happens, 
around 10,000 packages (many of which are huge) need to be rebuilt.

Personally I don't see why cmake needs to be updated to the most stable 
release more than once or twice a year, maybe 4 at an absolute maximum 
for each quarterly?  Certainly nowhere near 21.

So, something like UPDATE_LIMITED, which accepts a list of options that 
might include something like:

 abi

   Only update within stable ABI releases.  Any major update is
   forbidden without extensive bulk builds.  This could even include
   a semver tag (abi=3.x or whatever) for pkglint to verify.

 bootstrap

   Package is used by bootstrap or is a critical infrastructure package,
   and must only be updated once verified on all supported platforms.

 lts

   Similar to abi, but e.g. in my fork I've reverted haproxy back to the
   LTS release which is supported until 2029 because the bleeding edge
   releases cause regressions and there's absolutely no need to use them
   while there is such a generous LTS offering.  Again could support a
   semver tag.

 portability

   Package has shown a history of causing regressions or needs special
   handling, e.g. PLIST quirks, and committer must seek help for
   testing.  Things like ghostscript.

 quarterly

   Package is depended upon by many other packages, and thus should be
   updated at most once per quarter, pkglint can then parse doc/CHANGES*
   to issue errors.

Just some ideas, I'm sure there are others.  Thank you for finally 
considering this.

--
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com