Re: Bug#844052: glib2.0: FTBFS on !linux due to libmount
Hello,
Some background and request for help on porting libmount.
Samuel
----- Forwarded message from Andreas Henriksson <andreas@fatal.se> -----
From: Andreas Henriksson <andreas@fatal.se>
To: Michael Biebl <biebl@debian.org>
Subject: Re: Bug#844052: glib2.0: FTBFS on !linux due to libmount
Cc: Samuel Thibault <sthibault@debian.org>, 844052@bugs.debian.org, libmount-dev@packages.debian.org
Date: Wed, 23 Nov 2016 17:40:44 +0100
X-Spam-Level:
X-Spam-Status: No, score=0.8 required=8.0 tests=BAYES_50, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.1
Message-ID: <[🔎] 20161123164044.GA7902@fatal.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Hello all.
Sorry for the long reply below, but I feel a history lesson is needed
to explain what's up.
On Wed, Nov 23, 2016 at 04:28:02PM +0100, Michael Biebl wrote:
> Am 12.11.2016 um 02:15 schrieb Samuel Thibault:
[...]
> > glib2.0 currently FTBFS on !linux because debian/rules inconditionally
> > enables the use of libmount, available on Linux only. The attached
> > patch fixes this.
>
> Seeing that libmount1 is arch:any, I do not immediately see a reason why
> libmount-dev has to be arch:linux-any.
> So I'd rather see that architecture restriction dropped. I've CCed their
> maintainers.
>
> Andreas, can you comment here please?
Historically (= predating my involvement) each architecture has provided
their own mount/umount program implementations via arch-specific
packages. On linux that package is called simply "mount".
(Personally I don't see the reason why it's a separate package rather
than just installing those files only on linux-arch binaries of the
util-linux package like several other linux-only files are already
handled but feedback from other u-l maintainers preferred "not rocking
the boat" so this hasn't been changed.)
When updating from the 2.20.x util-linux we used to ship pre-jessie, to
a modern implementation of util-linux, some parts of the arch:any
util-linux package started depending on (= being linked to) the newly
developed libmount.
(Between 2.20.x (pre-jessie version) and 2.25.x (jessie version) the
"legacy mount" implementation of mount/umount was rewritten as a
libmount and a new mount/umount implementation on top of that.)
Fwiw, The new libmount should be designed in a way that's theoretically
portable. Unfortunately noone has volunteered to implement the
os-specific parts for anything except linux though.
To resolve this back before jessie release (so my memory is a bit fuzzy)
I looked at and it seemed complicated to try to get the programs linking
to libmount to be able to build without it.
I though noticed that I could pretty easily patch libmount to be able to
build without the "context" part which provides the (os-specific) mount
operations. This means libmount becomes a simple utility library which
doesn't provide any mount operation functionality on non-linux. None of
the util-linux programs that was provided on non-linux seemed to need
the context part of libmount at the time (and still doesn't, but who
knows how long that'll last) so making libmount arch:any after getting
my patch to make it build on non-linux upstream solved the issue of
being able to build a modern util-linux on non-linux.
The following commits should be the relevant ones:
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=e624bc558b9148b004c7908f12fad35038e3f5af
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=200cdfa8b1ba1e6827f8f0cd9b26eee7bcfd2ac5
Also this might be worth noting:
$ for a in $(dpkg -L util-linux | grep bin/ ) ; do ldd $a | grep -q libmount && echo $a ; done
/bin/lsblk
/bin/mountpoint
/sbin/cfdisk
/sbin/fsck
/sbin/fstrim
/usr/bin/lslocks
(All of these might not be installed on a non-linux system though.)
The "correct" solution to this issue is in my not so humble opinion that
someone volunteers to implement the context bits for their platform if
they want it supported. That should also mean we can start building the
"mount" package on that platform (and drop any previous arch-specific
package providing the mount/umount programs).
I guess the "correct" solution is about as likely to happen now as it
was when I was asking around to find non-linux architecture porters to
take on solving this initially. (At the same time I have to say hurd
porters has been doing a great job at maintaining util-linux portability
in many ways.)
Someone has to decide where we draw the line about spreading around
hacks all over the distribution rather than solving the core problem.
Somehow I guess a configure switch in glib isn't going to be the thing
drawing that line. (IMO the hacks in the base system are much uglier and
if those by themselves doesn't motivates us to require architectures
to implement libmount context support for their platform to be part of
Debian, then I think we're probably going to allow solving it in random
packages in whatever way anyone suggests.)
The above should be the long version of why libmount is arch:any.
Over to why libmount-dev isn't, well as you now know libmount can't
really be considered as "working" on non-linux so I don't want external
programs to suggest it's a bug that *I* must solve for them when
their application pulls in libmount-dev and fails to build or work
on non-linux. The headers will likely expose the context symbols which
are not available in the non-linux libmount shared object. Please feel
free to prove to me that we can provide libmount-dev on non-linux,
either by implementing the context parts or otherwise and I'll happily
switch it over. But please do not put more pressure on the util-linux
maintenance both because I'm already about to eject myself from it
as well as I'm very set on not ending up stuck in the corner where I had
to do a ton of work to dig us out of to have Debian be able to move
along and benefit from all the good work that's happening in new
upstream releases.
HTH.
Regards,
Andreas Henriksson
PS. I'm several times heard people say based on pure assumptions that
upstream doesn't accept portability patches, when in fact util-linux
upstream will accept just about any ifdef-hell you can throw at him.
This can easily be verified by looking at the upstream git history
and/or code. Though upstream will rely on you keeping the non-linux
path compiling/working so you might want to refactor things to avoid
ifdef-hell even if your ifdef-hell patch will get accepted as is. There
really is no excuses for people who care about portability to not get
involved upstream!
----- End forwarded message -----
--
Samuel
c> ah (on trouve fluide glacial sur le net, ou il faut aller dans le monde reel ?)
s> dans le monde reel
c> zut
Reply to: