[Debian GNUstep maintainers] Trixie goal: Multi-Arch

[Yavor Doganov]

So... this turned out much complex than I thought.  But it's certainly
doable and I think I'm ready with all of the changes.  Details below
(and sorry for replying to myself).

On Wed, 01 Jan 2025 17:35:19 +0200,
Yavor Doganov wrote:
>   * gnustep-make will need a Debian-specific patch to add
>     /usr/include/$(DEB_HOST_MULTIARCH)/GNUstep to the compiler's
>     header search path.

Well, not only this.  It's a new layout; I named it debian-multiarch.

>   * Because <GNUstepBase/GSConfig.h> is an arch-specific header,
>     gnustep-base must install its headers at
>     /usr/include/$(DEB_HOST_MULTIARCH)/GNUstep.

For consistency, it's better to install all headers there.  It's also
easier to support.

>   * I don't know what to do with packages like gnustep-sqlclient and
>     steptalk which include dynamically loadable modules (bundles) in a
>     non-multiarch location (/usr/lib/GNUstep).  I guess tests will
>     show what to do here.
>   * Likewise, I don't know what to do with all the frameworks which
>     have the actual library in /usr/lib/GNUstep and only .so(*)
>     symlinks in /usr/lib.  Again, testing is necessary.

There is no way; we have to move the entire GNUstep System Library
directory to /usr/lib/${DEB_HOST_MULTIARCH}/GNUstep.  Ironically, by
switching to the new layout all apps could declare Multi-Arch: same if
it wasn't the /usr/bin or /usr/games symlinks (a Debian/FHS
requirement).  Thus, it would have been possible to do "apt install
foo.app:armhf" on and amd64 machine and run the app through qemu.  Or
install in on an arm64 machine and run it natively if the CPU supports
that.

>   * Some library packages may need a pass through NEW if we have to
>     introduce a -common package, moving stuff in /usr/share there.

Only gnustep-make must pass through NEW for the new gnustep-multiarch
binary package which will be Multi-Arch: same and will contain the
symlinks at /usr/lib/${DEB_HOST_MULTIARCH}/GNUstep to arch-independent
directories at /usr/share.  dbuskit and renaissance must pass through
NEW as well but it can be done after the transition.

The required changes to the upstream code are not so many.  For
gnustep-make:

$ diffstat debian/patches/multiarch.patch 
 GNUstep-strict-v2.conf.in                       |    1 
 GNUstep.conf.in                                 |    1 
 GNUstep.csh.in                                  |    8 ++
 GNUstep.sh.in                                   |    9 ++
 common.make                                     |   15 ++-
 config.make.in                                  |   14 +++
 configure.ac                                    |    8 ++
 filesystem.csh.in                               |    9 ++
 filesystem.make.in                              |   24 +++++-
 filesystem.sh.in                                |    9 ++
 gnustep-make/FilesystemLayouts/debian-multiarch |   94 ++++++++++++++++++++++++
 11 files changed, 185 insertions(+), 7 deletions(-)

That's without the comments but you get the idea.  Since
/etc/GNUstep/GNUstep.conf is not in a multiarch location and its
contents are the same on every architecture, some GNUSTEP_SYSTEM_*
variables will contain the unexpanded multiarch triplet.  There's code
in filesystem.make to expand the variable (with a shortcut if
DEB_HOST_MULTIARCH is already defined) and also in
GNUstep.sh/filesystem.sh so that sourcing GNUstep.sh gives correct
results.  A new variable GNUSTEP_FILESYSTEM_LAYOUT is exposed because
there are conditionals for the variables' expansion only if its value
is "debian-multiarch".

gnustep-base needs a patch to expand the variables at configure time
so that the actual directories are recorded as the library's hardcoded
defaults.  Also, it needs to expand them at runtime when parsing
GNUstep.conf.  The DEB_HOST_MULTIARCH variable is used if it's defined
(usually when building a Debian package), othwerwise dpkg-architecture
is spawn to obtain its value.

$ diffstat debian/patches/multiarch+cross.patch 
 Source/NSPathUtilities.m |  101 +++++++++++++++++++++++++++++++++++++++++++++++
 Tools/autogsdoc.m        |    2 
 configure.ac             |   25 +++++++++--
 cross.config             |   18 ++++----
 4 files changed, 132 insertions(+), 14 deletions(-)

gnustep-gui needs a tiny patch only for cross-building and
gnustep-back does not require any patches.

These packages FTBFS with the new layout:

Level 1:
  gnustep-base
Level 2:
  dbuskit
  gnustep-corebase
  gnustep-gui
  gnustep-netclasses
  gnustep-performance
  pantomime
  rsskit
  sbjson
  sope
  universal-detector
Level 3:
  camera.app
  cenon.app
  charmap.app
  gnustep-sqlclient
  gomoku.app
  gorm.app
  grr.app
  lynkeos.app
  paje.app
  sogo
  systempreferences.app
  unar
Level 4:
  gnustep-dl2
  gworkspace
Level 5:
  addresses-for-gnustep
  steptalk
Level 6:
  adun.app
  agenda.app
  gnumail

With the exception of gnustep-base, the fixes are fairly trivial --
updating the .install/.links files or replacing some hardcoded paths
in debian/rules.  All of them available on my filesystem.

I also tried a cross-build on amd64 for armhf.  This is the list of
packages that FTCBFS:

Level 1:
  gnustep-base
Level 2:
  gnustep-gui
  sope
  universal-detector
Level 3:
  camera.app
  cynthiune.app
  lynkeos.app
  popplerkit.framework
  sogo
  unar
Level 6:
  adun.app

Those who also FTBFS will be fixed during the transition; the rest we
can fix later as these are not RC bugs.  Again, patches are available.

During the transition most apps will continue to work fine but some
that have bundles will be broken as -base will no longer look at
/usr/lib/GNUstep to find them.  I guess we can live with that for two
weeks.

Alex, what do you think?  Are we going to do this or not?  Can you
manage so many uploads?  (If it's inconvenient for you to reply by
email, please contact me on IRC.)