Re: Upcoming 0.26.0, please review release notes

[Yavor Doganov]

В Tue, 12 Dec 2017 10:24:27 +0000, David Chisnall написа:
> On 11 Dec 2017, at 21:04, Yavor Doganov <address@hidden> wrote:
>> Superfluous bumping is not so bad as retaining the SONAME if
>> there's ABI breakage but it's not a good practice and leads to
>> unnecessary burden for users and distros.
> 
> While I agree that it’s bad form, at least for FreeBSD it doesn’t
> make any difference for the packagers.  We will rebuild all of the
> packages that depend on -base when there are any changes to the
> -base library, whether the SO version has changed or not.

It makes a big difference for Debian because it triggers a lengthy
process which needs intervention from the ftpmasters and the release
team.

> It takes less than 24 hours to build the entire 30,000 package set on a
> single machine these days and it’s far better to burn some cycles
> unnecessarily than to ship a package set with ABI breakage.

ABI breakage is a bug that has to be detected and fixed, rebuilding
the reverse dependencies just sweeps it under the carpet.  Some people
use the library for their own software (not packaged or not even
available to the general public), so the "cure" would be completely
useless for them.  That's the whole point of library versioning, and I'm
surprised that for FreeBSD it doesn't make any difference.  If FreeBSD
update their C library, do they trigger rebuilds of all reverse
dependencies?

Debian supports 22 architectures, some of them very slow.  I may be
mistaken, but it also has much more packages than FreeBSD, so
unnecessary rebuilds are not an option.  This approach also doesn't
work with Debian's release process, where there are 3 stages
(different suites) and packages migrate from unstable to testing,
which at some point is frozen and becomes the new stable release.  The
GNUstep stack is tied to other libraries so spurious rebuilds will
entangle large sets of packages and would prevent their migration to
testing.

For example, SimpleAgenda/0.44 is now 5 days old but it can't migrate
to testing because it is blocked by a libical transition.  Until all
of libical's reverse dependencies are rebuilt on all release
architectures, it'll stay in unstable:

https://tracker.debian.org/pkg/agenda.app

If we upload gnustep-base/1.26 without coordination and approval, the
libical transition will collide with the gnustep-base transition so
all of libical's and gnustep-base's reverse dependencies will be
blocked and would have to migrate together.  Imagine a bug (build
failure of just one package on one architecture), the whole set of
packages will wait for the bug to be fixed.  Meanwhile, if the ICU
maintainer uploads his new library, there's another collision and the
set of affected packages grows.

Mass rebuilds simply don't scale for Debian.

> Even if the ABI is backwards compatible, there may be changes to the
> headers that will cause dependent software to enable new features at
> compile time, so skipping a rebuild is usually a bad idea.

For such packages rebuilds can be scheduled on a case-by-case basis.