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!
