| Message ID | 20200513222409.28811-1-brice@waegenei.re |
|---|---|
| Headers | show |
| Series | Fix and update udisks | expand |
On Thu, May 14, 2020 at 12:24:09AM +0200, Brice Waegeneire wrote: > This patchset update udisks and fix a startup error. > > Brice Waegeneire (5): > gnu: udisks: Update to 2.8.4. > gnu: udisks: Appease guix lint. > gnu: libblockdev: Appease guix lint. > gnu: libblockdev: Add input 'xfsprogs'. > gnu: libblockdev: Set default configuration directory. > > gnu/packages/disk.scm | 15 +++++++++++---- > gnu/packages/freedesktop.scm | 5 ++--- > 2 files changed, 13 insertions(+), 7 deletions(-) > > -- > 2.26.2 > $ 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?
I pushed all the patches except for the xfs one. Let me know if it works :)
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
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?