Re: pkgsrc stability vs. updates

[Jason Bacon <jtocino%gmx.com@localhost>]

On 3/7/25 20:24, Jason Thorpe wrote:
> > On Mar 7, 2025, at 1:58 PM, Thomas Klausner <wiz%NetBSD.org@localhost> wrote:
> >
> > Perhaps we should reduce our portability claim to only mention the
> > operating systems where we have such people (I think NetBSD, macOS,
> > Illumos, some other Solaris?).
>
> This one sparked me to chime in from the peanut gallery.
>
> I’ll speak as someone who:
>
> 1- Runs pkgsrc primarily on NetBSD.
> 2- Runs pkgsrc secondarily on macOS.
> 3- Maintains a pkgsrc package of a program of my own making (sysutils/nabud) that’s autoconf’ified and that I personally use on NetBSD and macOS (and install on those systems via pkgsrc), and nominally test on Linux (Ubuntu), FreeBSD, OpenBSD, and Cygwin (using virtual machines) (I tried DragonFly but it was too weird).
>
> I care about my program working on those other platforms, but “pkgsrc package for those platforms works properly” is a tertiary concern, at best, mainly because those other platforms already have their own “native” things and if someone cares enough, they can package my program up for it.  (A friend of mine did this for Arch Linux, actually.)
>
> My primary concern for pkgsrc is always NetBSD, and second to that, macOS (I prefer pkgsrc on macOS because I prefer to build from source).  NetBSD hosts pkgsrc, and it’s the native system for the platform, so I think NetBSD should be the “Tier 0” platform and everything else Tier 1 or lower.
>
> And yes, wiz has definitely had to wag his finger at me for breaking something that I missed in my own environment, but that’s usually because I’m a pkgsrc casual and forget to turn on all of the pkgsrc sanitizers whenever I break^Wchange something.
>
> -- thorpej

I think this viewpoint, which is perfectly fine for some use cases, is a 
good approximation of the pkgsrc culture.  But it doesn't work for some 
of us who need reliable package management on platforms other than 
NetBSD, and hence it may be that we need two separate package managers 
going forward.

The big advantage of pkgsrc/dreckly from my perspective is the ability 
to install the exact same software on multiple platforms, whether or not 
we have admin privileges.  The vast majority of scientific computing is 
done on Linux and macOS.  The ability to install the exact same software 
on personal Macs and Linux HPC clusters removes hurdles to getting the 
analysis done, and removes doubts in the minds of peer reviewers 
concerned about consistency of results.

Constantly facing grant deadlines in the publish-or-perish world of 
scientific research means we can't afford delays due to regressions 
caused by routine software updates.

One example: My rna-seq meta-package installs all the tools needed for a 
typical gene expression comparison, and requires 82 packages:

> sbmake show-depends-recursive | wc -l
      82

It's common for at least one of these to get broken during any given 
quarter in pkgsrc.

Quarterly branches were always a way to avoid these issue, albeit not an 
ideal one.  Preventing regressions in the first place is a much better 
solution.  We can't prevent every regression, of course, but allowing a 
regression can almost always be a deliberate decision if we have the 
right tools and procedures in-place.

--
Life is a game.  Play hard.  Play fair.  Have fun.