bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk

[Bengt Richter]

Hi Marius,

On +2019-11-03 18:28:40 +0100, Marius Bakke wrote:
> Bengt Richter <address@hidden> writes:
> 
> > On +2019-10-28 23:29:16 +0100, Marius Bakke wrote:
> >> The `lsblk` program requires root privileges in order to detect file
> >> systems and UUIDs.  I'm guessing your distribution makes it setuid root?
> >>
> >
> > It doesn't  look like it to me (the following snip is from TTY4, where I 
> > enabled guix paths and environment,
> > so I can see ~/.guix-profile and /usr stuff at the same time):
> 
> [...]
> 
> 
> > $ which -a lsblk|xargs readlink -f|xargs stat
> >   File: 
> > /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk
> >   Size: 135560      Blocks: 272        IO Block: 4096   regular file
> > Device: 10304h/66308d       Inode: 1186253     Links: 2
> > Access: (0555/-r-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> > Access: 2019-11-01 02:38:11.782574923 -0700
> > Modify: 1969-12-31 16:00:01.000000000 -0800
> > Change: 2019-10-08 18:18:48.226579757 -0700
> >  Birth: -
> >   File: /usr/bin/lsblk
> >   Size: 124992      Blocks: 248        IO Block: 4096   regular file
> > Device: 10304h/66308d       Inode: 264652      Links: 1
> > Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> > Access: 2019-11-01 02:38:55.354524750 -0700
> > Modify: 2019-06-27 03:04:01.000000000 -0700
> > Change: 2019-07-06 00:59:13.620416635 -0700
> >  Birth: -
> > $ 
> > ┌───────────────────────────────────────────────────────────────────┐
> > │ I see Access: is 0555 vs 0755, so doubt if that should be changed │
> > └───────────────────────────────────────────────────────────────────┘
> 
> Indeed, there are no setuid bits there.
> 
> I had a look at the lsblkd source code, and found that it has an
> optional dependency on udev:
> 
> https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c
> 
> I tried building util-linux with udev support, and got the same output
> you expected without needing root privileges:
>

Sounds great ;-)

> (define-public util-linux/udev
>   (package/inherit
>    util-linux
>    (name "util-linux-with-udev")
>    (inputs
>     `(("udev" ,eudev)
>       ,@(package-inputs util-linux)))))
> 
> Now, eudev already depends on util-linux, so adding udev support to the
> regular 'util-linux' package would introduce a circular dependency.
> 
> I'm not sure what the best approach here is.  We could add a
> 'util-linux-minimal' for use in package inputs, and/or add a
> udev-enabled variant to %base-packages.
> 
> Thoughts?

I'm a guix newbie :)

I don't yet understand the internal dependency machinery of guix,
so I'm wondering about the exact nature of the circularity.

Is it really a kind of (let((... that needs to be a let*((...
at some level? And which level of dependency are we talking about?

I mean, everything is ultimately dependent on sources and translators
in succession, but we identify intermediate collections and call them
libraries or packages or scripts or executables etc.

E.g., if part of the build sequence produces an obj library, is an 
interdependency
between two library elements a circular dependency if that requires two passes
for the linker to resolve? (i.e., the second is dependent on the library, but
only as container of the other element).

What is the chain of dependency that yields a user cmdline lsblk executable
on my $PATH ? As a user, I don't much care beyond hoping guix pull will keep
the functionality at my finger tips (thanks maintainers :), but...

But once I start wanting a handy customization of something, I want it
to be trivial to compose trivial things, which for me starts at a shell
command line, composing a one-liner, and then writing two-line scripts
when I find myself re-typing a lot, and so on, to things like examples
in info guile, including C extensions.

So, my thought is that whatever the solution is that puts lsblk on my $PATH,
I want the system for it to be cherry-picker-friendly.

By that I mean I want to be able to make tiny things from cherry-picked 
("stolen" ;-)
snippets/elements of something big and having the net result be minimal -- 
unless I really
do e.g. want a busybox monolith for other reasons than puts "Hello World".

Also, being a command line user, I want to be able to access any functionality 
from there ;-)

That BTW includes graphics: I would like to be able to run any GUI program in 
headless mode
and get graphic buffer output, or streams.

Likewise, I would like guix build tools to be able e.g. to cherry-pick the 
sources of a browser
to get the functionality that renders an html <table ...> ...</table> to sRGB 
buffer
(assuming sources are modularized cherry-picker-friendly :) without 
incorporating more than necessary,
(and automatically doing the license/attribution stuff ;-)

IOW, sort of treating any large application's (or a kernel's! :) sources as a 
kind of library.
Of course, I know cherry-picker-friendly is a dream, but I think it's a nice 
dream :)

So I think it should be a design goal for FOSS to be easily snarfed.

Life could be a bowl of cherries if enough people descide to be friendly ;-)
--
Regards,
Bengt Richter