tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Can we stop revbumping the world please?
On Sat, Nov 09, 2024 at 10:34:16PM -0500, Greg Troxel wrote:
> nia <nia%NetBSD.org@localhost> writes:
>
> > I don't see why we always need the latest version of these huge unstable
> > C++ libraries. Developers don't target the latest version since their
> > users are on LTS linux distributions. Often we are fixing fallout related
> > to them.
>
> This is a really good point. One of the bugs with pkgsrc is that even
> if most think it is wise to be slow in updating, it only takes one to
> update. I would prefer to have consensus about when it's time.
>
> The real issue is that icu is unstable; a reasonable package would have
> an ABI break infrequently, and the new version would be satisfactory at
> both build and run time for code that uses it. Many packages are like
> that -- which means we don't need to talk about them.
I'd love a "scientific" method for determining the "most viable" version
of an unstable library, other than running bulk builds on many platforms
at once - which is probably a doomed proposition, given the resources
required.
ICU 73.2 seems to be the one of the most popular versions at the moment
(according to repology). It was released last year. From what I can see,
it's mostly projects around our size (in terms of user and developer
activity) that are shipping it. Debian Unstable is shipping an even older
version from 2022, which somehow means that pkgsrc is less unstable than
Debian Unstable.
Similarly, boost 1.83.0 seems disproportionately popular. This was
also released last year.
There's not much logic overall to this, so it's hard to see a path forward
other than "one update to unstable c++ library per year, must be at
beginning of branch, make it count".
I'd much rather be wasting CPU cycles backporting security patches than
wasting CPU cycles rebuilding the tree due to an ABI bump.
Home |
Main Index |
Thread Index |
Old Index