Re: pkgsrc-2024Q3 net/tigervnc is broken on sparc64

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Mon, 28 Oct 2024 10:59:56 +0000
David Brownlee <abs%absd.org@localhost> wrote:

> There is another interim option to allow access to a working older package
> for specific platforms in cases like these - add it to pkgrsc-wip (I wonder
> in fact if this should not be explicitly mentioned somewhere in the docs).
> 
> Ensure the package COMMENT and DESCR state clearly why it is there as an
> older version, and probably name the directory tigervnc113
> 
> It doesn't help getting a fix, but may make like a little easier in the
> meantime
> 
> David

I'm not a pkgsrc developer, my interests lie elsewhere. There may be
different ways of solving such issues. I've been using pkgsrc for many
years and hitting these problems here and there, especially with older
SPARC hardware. So from the usability point of view:

1. New software versions introduce regressions, because many developers
don't use BSD and most of them don't test on SPARC. NetBSD provides
pre-built binaries for different architectures, but it is unreasonable
to expect that every single package is going to be thoroughly tested
for each stable release. So broken package will occur and then can
pkgsrc deal with the issue in a graceful manner?

2. Many pkgsrc users may not be developers, so it is unreasonable to
expect them to build software from sources or dig through previous CVS
revisions. They simply want to run "pkg_add XXX" and get a working
package. This is a basic usability requirement. Packages may depend on
shared library version symbols, etc, so it's not as simple as installing
pkgsrc-2023Q3 and then cherry picking individual packages from
pkgsrc-2022Q4 or earlier releases, in case of package regressions. This
may not work.

3. If there are known regressions, it may be minimum effort to simply
copy previous version to current stable pkgsrc branch and kick off a
build job just for that package. All the make files already exist and
there is nothing to fix. For somebody who has CVS commit rights, it
could be a few minutes work. This way you end up with two packages - V1
and V2, which may conflict each other and cannot be installed
simultaneously. But at least users have a choice and are not denied
access to binary packages. When V2 regressions are fixed, simply get
rid of V1.

If nobody is using this package on SPARC apart from me, then don't worry
about it. I know how to revert to a previous version and how to build
from source. Others may not have the time or the knowledge to do this.
And this issue is likely to crop up again and again, for various other
packages. Simply removing a broken package and waiting for the next 6
months for upstream to fix it is not ideal. Maybe offer alternatives if
they are readily available and people ask for them.