pkgin havoc and pkgsrc binaries availability

[steve%prd.co.uk@localhost (Steve Blinkhorn)]

Thank you both for the clues.  I've been slow to respond because in
the havoc, my entire network management setup got demolished.  I run
a geographically dispersed network of NetBSD machines using VNC to tie
them together, using multiple virtual screens and a custom version of
icewm, from a time when pkgsrc icewm was too buggy.

All the many symlinks to shared libraries had been destroyed, but it
took a long time to work out that this was the root of the problem.  It
strikes me that pkgin must have been self-regarding to the point
of solipsism.  Do I need to do anything to make sure pkgin never does
anything like this to me again?

Talking about upgrading to more recent releases raises an important
issue about the status of NetBSD.  I moved to NetBSD after the
demise of BSD/OS, on the advice of Peter Seebach, largely because of
the stability, platform-independence and backward-compatibility.  I
use it to deliver services from secure data centres, use packages, and
develop software which, in its own context, in be bleeding edge, but not
from an OS-design point of view.

Moving stable customer-facing services to a newer release poses
technical and commercial challenges.  For instance, before this episode
I had three working browsers, firefox60, arcticfox and palemoon.  Up-to-date
firefox and arcticfox segfault immediately on startup.  I was able to
rescue firefox60 by restoring some symlinks, but current firefox
and arcticfox just segfaults on startup.  Palemoon works.   Updating
the OS on remote colo servers can be very challenging, so better to
let sleeping dogs lie.  And the same is true for the office machine
that runs name service, certificate updating, timed, mail servers and
the like.

It seems to me that the pressure to constantly upgrade, and the
removal of binary packages for earlier releases, disadvantages those of
us who use NetBSD as a service delivery platform, because someone
thinks we *ought* to work more like them, or can't perhaps imagine our
sort of usage.  I've been using NetBSD since 1.x  But I can't add
packages that were once there but I happened not to have downloaded
for the machine that runs DNS, mail mservice etc. for my domains,
because that's still on 7.x and otherwise contentedly doing its job.
Everything else is currently 9.x, but if current policy prevails I'll
have to upgrade six machines, three of them remote, or lose access to
the pkgsrc binary collection.

So is NetBSD for real-world use, or just for boundary-pushing?
The policy of faster bumping of major release version numbers is
doing me harm, and is likely to do more.  

--
Steve Blinkhorn <steve%prd.co.uk@localhost>

You wrote:
> 
> * On 2026-03-25 at 16:59 GMT, Greg Troxel wrote:
> 
> >steve%prd.co.uk@localhost (Steve Blinkhorn) writes:
> >
> >> There are a few hundred lines in  the error log such as these:
> >>
> >> pkg_add: Package `libjpeg-turbo-3.1.3' conflicts with `jpeg-[0-9]*',
> >> and `jpeg-9f' is installed.
> >> pkg_add: Installed package `jpeg-9f' conflicts with
> >> `libjpeg-turbo-[0-9]*' when trying to install `libjpeg-turbo-3.1.3'.
> >
> >pkgin has baked in an assumption that when you use a binary package
> >repo, then every package you have will be from that repo.  Yes, you can
> >rebuild things locally from compatible sources, and do other things if
> >you know what you're doing, but you're off the rails.
> >
> >pkgsrc changed the default from jpeg to jpeg-turbo.  That's the root
> >cause of the above error message.
> 
> Newer pkgin would handle this upgrade correctly, and newer pkgin also 
> detects when there is a newer version of pkgin available from the repo 
> and will upgrade itself first before performing the rest of the upgrade, 
> to ensure that such fixes are in place.
> 
> As you are going through the JPEG_DEFAULT switch which was last April, 
> it's likely you were trying to upgrade using a pkgin version prior to 
> these fixes unfortunately.
> 
> Up until I implemented these pkgin improvements I've always instructed 
> my own binary package users to 'pkg_add -U pkgin' first, but I don't 
> think the NetBSD repositories do that.
> 
> Sorry that it caused breakage, but hopefully at least from the pkgin 
> side of things this shouldn't happen again in the future.
> 
> -- 
> Jonathan Perkin                    pkgsrc.smartos.org
> Open Source Complete Cloud   www.tritondatacenter.com
>