pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkgsrc-2024Q3 net/tigervnc is broken on sparc64
On Mon, 28 Oct 2024 at 13:07, Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:
>
> 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.
Agreed.
> 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.
The pkgsrc project is somewhat resource constrained. As you know
there are a very large number of platforms but a limited number of
developer time. Less common platforms in particular rely on motivated
individuals to "add their shoulder to the wheel" to keep things
working.
Duplicating packages by adding older versions increases ongoing
maintenance, as it is not only the time to add the package, but
keeping that older package working as its dependencies update (looking
at the patches in older firefox versions is a good example). For some
packages (points at older firefox again), this is generally agreed to
be worth the effort, for other packages it may not be.
> 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.
As I mentioned, pkgsrc-wip may provide a useful compromise for those
building from source. They can checkout pkgsrc-wip into their existing
pkgsrc tree and build additional packages from there. I've added a
wip/tigervnc113 entry there - if you have time to test and confirm if
it is useful that would be appreciated.
An additional question may be whether it makes sense to add a
"BROKEN_ON_PLATFORM+= NetBSD-*-sparc" to net/tigervnc (with a comment
referencing wip/tigervn113) to stop non functional binaries being
built
Thanks
David
Home |
Main Index |
Thread Index |
Old Index