From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Date: Wed, 6 Nov 2019 14:39:10 -0800 Message-ID: <20191106223910.GC55508@PhantoNv4ArchGx.localdomain> References: <20191026012248.GA119672@PhantoNv4ArchGx.localdomain> <87tv7stsg3.fsf@devup.no> <20191102144256.GA931@PhantoNv4ArchGx.localdomain> <87mudcoomv.fsf@devup.no> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35375) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSTy8-0008Fm-KB for bug-guix@gnu.org; Wed, 06 Nov 2019 17:40:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSTy7-0007AL-51 for bug-guix@gnu.org; Wed, 06 Nov 2019 17:40:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:60787) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iSTy7-0007AH-0H for bug-guix@gnu.org; Wed, 06 Nov 2019 17:40:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iSTy6-0000bu-Kb for bug-guix@gnu.org; Wed, 06 Nov 2019 17:40:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87mudcoomv.fsf@devup.no> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Marius Bakke Cc: 37931@debbugs.gnu.org Hi Marius, On +2019-11-03 18:28:40 +0100, Marius Bakke wrote: > Bengt Richter 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 ...
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