Emilio Pozuelo Monfort wrote:
> Go ahead with this.
Thanks a lot for the green light. Both uploaded; gnustep-base would
need a give-back on armhf at the right moment as it got picked by the
arm64 buildd again.
> And yes, a combined list would be appreciated if the rebuilds need
> to be done in order. If order doesn't matter and I can schedule all
> the levels in one go, then I can combine them myself.
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. (Incidentally, this should assist
transitions too as I think they will migrate as soon as their rdeps
with autopkgtests are binNMUed and their tests pass. Previously, the
whole GNUstep stack migrated as one unit, usually waiting for the
slower arches to catch up.)
So the order will be undefined now if the binNMUs are scheduled at
once. Packages up the stack that happen to build before their
dependencies below (e.g., lusernet.app building before pantomime) will
end up with warnings like:
| Linking app LuserNET ...
| /usr/bin/ld: warning: libgnustep-base.so.1.25, needed by
/usr/lib/libPantomime.so, may conflict with libgnustep-base.so.1.26
This is harmless and relinking is not needed, but the lusernet.app
package will be broken for users (the program will abort on startup)
until pantomime is binNMUed. I guess that's somewhat reluctantly
allowed during transitions ("unwritten law"); some packages are broken
right now in sid for users who upgraded -base and -gui because of the
programs from the -runtime packages which are available only for the
new library versions now.
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, so you can schedule binNMUs for
gnustep-performance
sbjson
sope
first, wait for them to be installed everywhere and then schedule all
the rest in one go. Alternatively, if the above is technically
difficult, schedule everything in one go and be ready for give-backs
on architectures where the wrong order leads to FTBFS.
And finally, if you feel now is not the proper time to experiment, you
can schedule them in batches, preserving the order and mimicking the
past transitions where the order naturally followed the dependency
chain.
Here is hopefully the complete list (I split them based on the
dependencies on the core libraries only to allow you to tweak the
binNMU changelogs, if you wish so; it doesn't matter otherwise):
Level 1
=======
# packages that depend only on -base
biococoa
dbuskit
gnustep-netclasses
gnustep-performance
mknfonts.tool
openvpn-auth-ldap
pantomime
rsskit
sbjson
sope
unar
# packages that depend both on -base and -gui
aclock.app
addresses-for-gnustep
affiche
batmon.app
camera.app
cenon.app
charmap.app
chess.app
cynthiune.app
edenmath.app
etoile
fontmanager.app
ftp.app
gnustep-examples
gomoku.app
gorm.app
gridlock.app
gtamsanalyzer.app
helpviewer.app
lynkeos.app
mpdcon.app
paje.app
pikopixel.app
plopfolio.app
poe.app
popplerkit.framework
preview.app
price.app
projectcenter.app
renaissance
systempreferences.app
terminal.app
textedit.app
timemon.app
volumecontrol.app
wrapperfactory.app
zipper.app
Level 2
=======
# only -base
gnustep-sqlclient
sogo
# both -base and -gui; applies for the next levels as well
agenda.app
gnumail
gnustep-dl2
gworkspace
lusernet.app
talksoup.app
viewpdf.app
Level 3
=======
steptalk
Level 4
=======
adun.app
Reverse dependencies that are deliberately omitted:
- fortunate.app (FTBFS, pending sourceful upload);
- gnustep-back (sourceful upload due at my sponsor's discretion; it
tracks -gui versioning closely);
- pantomime1.2 (scheduled for removal; no point rebuilding it).
