В Tue, 12 Dec 2017 10:24:27 +0000, David Chisnall написа: > On 11 Dec 2017, at 21:04, Yavor Doganov <ya...@gnu.org> 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. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
