On Thu, May 14, 2020 at 01:50:50PM +0000, Brice Waegeneire wrote:
> Hello Efraim,
> 
> On 2020-05-14 08:25, Efraim Flashner wrote:
> > $ guix gc --references
> > /gnu/store/g6pv8jfhi3m6a2wnvlwjcx4i3hjihnra-libblockdev-2.23 | grep xfs
> > 
> > it doesn't look like it actually links in xfs support. I see from the
> > configure output that the FS plugin is built and installed in %out/lib.
> > Does it work on xfs formatted partitions without linking to xfsprogs?
> 
> Listing all the references, 'btrfs-progs', 'dosfstools' and 'mdam' are also
> not linked but are present as inputs.
> 
> --8<---------------cut here---------------start------------->8---
> /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib
> /gnu/store/33y7wsvfh3i6mq9h7812pwagj8p2lrfd-libyaml-0.2.4
> /gnu/store/35afkywncrr5xsb4cxcljf6rpjcb7f61-gmp-6.2.0
> /gnu/store/5jf395qa3v4amdi60850rz2a15zlsrza-mpfr-4.0.2
> /gnu/store/5ydgg6rd9vqw0hf4a7ji65y4yw3ja665-lvm2-2.03.09
> /gnu/store/7ykddq56ssyqm1win3jlxm3ran94kq3q-libbytesize-2.2
> /gnu/store/9g1nq7qf5mkhbyjcyc0d7g9j02x3sdl2-argon2-20190702
> /gnu/store/9rk1sdzb9lqsi38knfi2pq5gqxfxi8d0-libgpg-error-1.37
> /gnu/store/9rvf68qxkq14sxajdp4gf8qqa026bjj2-kmod-26
> /gnu/store/a45p39mgqvfd8kjwibyr0q42k1mw7gmf-util-linux-2.35.1-lib
> /gnu/store/bjp2vcbdsmckv2b4f69bci1z9n0i43b6-eudev-3.2.9
> /gnu/store/cbrx0nl7qwrz1j3r19ylahrgilyr1n83-json-c-0.13.1
> /gnu/store/dh5klm7h2nh930lj3kgiaqkqd8vpvjaa-parted-3.3
> /gnu/store/dp0q63a7ykqwsfwn1c1wx81ak51l0vp3-ndctl-68
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31
> /gnu/store/g6pv8jfhi3m6a2wnvlwjcx4i3hjihnra-libblockdev-2.23
> /gnu/store/gfpgqvwrixhf3sf1bnzsfxzvld0nd8b7-nss-3.50
> /gnu/store/j9agmxk8iyjba4wvvam056s4n3phlg6h-gpgme-1.13.1
> /gnu/store/n2r0q34y5bjj3vd65p6nb64dghbgka01-volume-key-0.3.12
> /gnu/store/p2hkmh8rfw9qaspxlf0yd4qp1hzj0bc8-cryptsetup-2.2.2
> /gnu/store/q7hba8fqpix98qwcpf64izsf4wqhv1ij-libassuan-2.5.3
> /gnu/store/qc3k3kd458pgrqsc7ih641160q81npwq-libgcrypt-1.8.5
> /gnu/store/qvahafxrr2mcl4anjxdkkprrvd4k0xjj-pcre2-10.34
> /gnu/store/r7k859hmcnkazf492fasqvk25jflnfk6-xz-5.2.4
> /gnu/store/rmbxm1fg47b347kv1h5fb2w04nxqbsj6-glib-2.62.6
> /gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11
> /gnu/store/sdh81ijcxqlkns1c48lsdripfj34fmwq-dmraid-1.0.0.rc16-3
> /gnu/store/vqajm09by8dxxfl1fd7n45blfhzyg1gm-nspr-4.25
> --8<---------------cut here---------------end--------------->8---
> 
> libblockdev seems to use the commands provided by those packages[0].
> They, including 'xfs', should be in the propagated-inputs field, right?
> 
> [0]: https://github.com/storaged-project/libblockdev/blob/master/src/plugins/fs/xfs.c#L45-L51
> 
> - Brice

So to summarize some of our conversation yesterday on IRC, we don't need
to have some of the filesystem utilities as build inputs while building
libblockdev. Libblockdev shells out to the different utilities to make
use of their programs while interacting with the file systems.

We'd rather not propagate all the file system utilities. We could patch
the code itself in libblockdev so that when it shells out we give it the
a path to the store where that program lives. We could add a note to
libblockdev or udisks in the description telling people to install other
programs if they need more functionality. Another option is to wrap
udisks in the various filesystem programs so that they're available for
use by libblockdev.

I don't like the magic of "it works with udisks but not when I try it
manually", but I do like it when packages just work. I don't like the
idea of adding the note to libblockdev's description. I know I wouldn't
look there if udisks didn't work the way I expected. If udisks didn't
work the way I expected I don't know I'd check the description of the
package.

Currently udisks is the only package that uses libblockdev so
functionally there's not a lot of difference between wrapping udisks or
patching libblockdev, but that would change if other programs started
using libbockdev. I'm concerned about the maintenance cost of patching
libblockdev and making sure that the substitutions would need to be
re-checked on each update, but it seems like the best method for making
sure everything will just work.

I think our best option is to patch libblockdev to provide absolute
paths to the different binaries so that any program using libblockdev
will just work.

What do you think about that change?

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted