Bug#918844: transition: gnustep-base, gnustep-gui

[Yavor Doganov <yavor@gnu.org>]

On Sat, 12 Jan 2019 01:24:54 +0200,
Yavor Doganov wrote:
> Emilio Pozuelo Monfort wrote:
> > And yes, a combined list would be appreciated if the rebuilds need
> > to be done in order.
> 
> In previous transitions, the order was guaranteed because rdeps higher
> up the stack were in state BD-Uninstallable until the library packages
> they depend upon were rebuilt and installed.  But in this cycle we
> have relaxed the dependencies between the -base/-gui binary packages
> to allow co-installation of different library versions, thus
> supporting partial upgrades.

I would appreciate the release team's opinion regarding this
experiment; I think it failed not only because of the regressions [1]
when both library versions are installed but because testing migration
is now blocked by regression in gnustep-sqlclient's autopkgtests.

[1] https://alioth-lists.debian.net/pipermail/pkg-gnustep-maintainers/2019-January/004782.html

Should we switch back to tight dependencies, thus allowing only one
gnustep-{base,gui} version to be installed?  I believe that's also the
reason for the gnustep-sqlclient's autopkgtest failure in testing as
libperformance0.5 (from src:gnustep-performance) linked against
gnustep-base/1.25 is installed during the test.  If the dependencies
were tight the test would be skipped in testing.

Are you going to force gnustep-base to testing or you want me to do
something else?

> What's important is that any package in this category which compiles
> and runs tests at build time will FTBFS because the tests will abort.
> This is precisely what happened to me with sogo when I tested it for
> this transition; see #918795 for explanation (I closed the bug as it
> turned out that sogo builds fine).  TTBOMK, gnustep-sqlclient and sogo
> are the only rdeps that have tests,

Same problem here; gnustep-sqlclient and sogo failed to build on
kfreebsd-amd64 as the builds were attempted with non-binNMUed
gnustep-performance and sope/sbjson.

Other problems so far:

* lusernet.app was built against libpantomime1.2 on all release
  architectures + hurd-i386.  Builds for debian-ports are fine AFAICS.
  Would you schedule another round with the appropriate extra-depends
  or you want me to make a sourceful upload?

* All binNMUs on kfreebsd-i386 were in vain because gnustep-base is
  not installed there yet and gnustep-gui is not even built.

* There are some installability issues on kfreebsd-* due to libheif
  not being rebuilt for the last x265 transition.  Should I ask on
  -bsd/-wb-team for help here?

* 3 packages FTBFS on GNU/Hurd due to a known issue with the buildds;
  I asked Samuel to give them back.