Re: policy proposal: updating packages with many dependencies

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

* On 2025-03-27 at 21:43 GMT, Thomas Klausner wrote:

> I can get behind the 'bootstrap' list, but we need to come up with a
> workable procedures for when updates to these packages can be
> committed. Requiring a full bulk build doesn't sound reasonable; on
> the other hand, having 'bootstrap' finish a couple of platforms sounds
> like too little.  I'm not sure where the golden middle for this
> is. Perhaps building meta-pkgs/bulk-test-essential?

I don't think it needs a bulk build either, except maybe for a large 
change to bmake or something, just a test of a clean bootstrap plus a 
couple of packages to test functionality on as many platforms as 
possible.

I feel that if a user tries pkgsrc for the first time and cannot even 
bootstrap, that leaves a terrible impression, and I'd like to avoid that 
as much as possible.  There aren't that many packages in the bootstrap 
path, and most of them are absolutely critical to all pkgsrc operations,
so I don't think it's too onerous to expect that any changes to them are 
well tested and reviewed.

> But we need some infrastructure to test this, I don't think it's
> realistic to assume that committers can test on even 3+ platforms. If
> you could provide infrastructure for this, that would be appreciated.

Sure, dreckly can already do this automatically on 9 platforms, and nia 
has been doing great work at spinning up a lot of the more esoteric 
platforms and getting them back into shape.

> 'portability' is a new one for me. Do you have some more examples of
> such packages? I wasn't even aware that ghostscript was problematic in
> this respect. Do we enough of these that they should be part of this
> now?

Sorry, I meant textproc/groff, where the last update caused widespread 
breakage.  Basically any package that has a lot of OS-specific install 
code, or complicated PLISTs that have a high chance of breaking on 
updates, etc.  Maybe 'fragile' would be a better name?  Not sure.

> IMHO, 'lts' does not fit here. I think the proper solution for this is
> having foo and foo-lts packages, like the ESR packages we have for
> firefox; perhaps with some kind of lts.mk files that globally switch
> to the lts or the HEAD version, if other packages depend on them.

I think that works well for leaf packages like firefox.  I'm not sure 
how well it would work for packages like openssl that most of the tree 
depends on.

> I'm not convinced of the 'quarterly' category yet and would like to
> discuss that at some other time, if that's ok.

It might be that it should be merged with the proposed 'lts' but with a 
better name, as there are common reasons behind wanting them:

 * This is a really really important package, either in terms of it
   being a dependency for many other packages, or it being a fundamental
   part of service infrastructure.

 * Any update to it carries a huge amount of risk, and critical bugs may
   not be apparent until runtime.

 * Unless there are incredibly strong reasons for doing so, this package
   should remain on the most stable and well-tested release available,
   and only updated when absolutely necessary and in line with what most 
   other packaging systems are doing.

The proposed additions are good, but they are only concerned with build 
failures.  As someone who has provided over 20 million packages to 
thousands of users running critical operations on them, and had pkgsrc 
help support one of the largest cloud installations in the world that 
many of you will have unknowingly used, I have a strong interest in 
ensuring that the software that we package is robust and reliable, and 
avoid any potential whatsoever for a "pkgin upgrade" to break a 
customer's production environment and for me to get shouted at.

It's a very different level of risk compared to someone installing a few 
hundred packages to power their NetBSD desktop and maybe run some small
internet services.  I don't mean that disparagingly, I just want to 
emphasise the massive gulf in use-cases.  I'd like to accommodate both, 
and have some way to mark e.g. net/haproxy as having the potential to 
ultimately stop your phone backups from working that sysutils/neofetch 
does not, and that updates to them should be handled accordingly.

Cheers,

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