Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Please don't use IUSE=static-libs unless really necessary
Date: Mon, 19 Sep 2011 22:26:35
Message-Id: pan.2011.09.19.22.25.35@cox.net
In Reply to: Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary by Mike Frysinger
1 Mike Frysinger posted on Mon, 19 Sep 2011 12:05:39 -0400 as excerpted:
2
3 > On Monday, September 19, 2011 11:35:09 Michał Górny wrote:
4 >> On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote:
5 >> > > > by that token, i'll go ahead and remove glibc's static libraries
6 >> > > > since upstream doesn't even support static linking
7 >> > >
8 >> > > I'm probably ignorant so you'd have to elaborate more on that to
9 >> > > make me see a problem there.
10 >> >
11 >> > think about it a little bit. your system is using static binaries
12 >> > right now, and considering you like to push systemd + initramfs so
13 >> > much, i would have thought you'd realize the implications more
14 >> > quickly.
15 >>
16 >> Hm, I seem to fail to notice other static binaries than busybox. And I
17 >> don't think I use any specific configuration which makes me need static
18 >> binaries;
19 >
20 > by default, tools that are needed to easily recover a system
21 > (busybox/cryptsetup/lvm/etc...) are IUSE=+static, and every binary that
22 > goes into initramfs is statically linked.
23
24 By default? That's begging the question (logic sense) and consequently
25 does not properly support your blanket "your system is using static
26 binaries right now" statement.
27
28 That doesn't mean the statement is incorrect. I may well be using static
29 binaries of some sort, but I'm not aware of any (save for grub-static,
30 since I run amd64/no-multilib), and I'd love to know more about which
31 binaries they are, and whether static linking is really necessary for
32 them. Feel free to post a link as I've a feeling this is reasonably
33 basic, but evidently I'm not the only one who would find such info
34 educational and likely useful.
35
36 FWIW, no busybox here. It wouldn't build when I installed back in 2004,
37 so I package.provided it for later. I tried it again a couple times but
38 by then it was quite clear that it really was NOT needed, so eventually I
39 decided I had better things to do than tilt at that windmill. (I use a
40 second root image, updated AND TESTED when the system appears to be
41 working well, as my emergency recovery solution, thus don't need busybox.)
42
43 I run (partitioned) md/raid because I can feed appropriate assemble
44 instructions on the kernel command line, no initr* needed. I do NOT use
45 lvm because it would require either an initr* for the root and root-
46 backup images or keeping them separate, needlessly increasing complexity
47 now that md/raid handles partitions transparently, and triggering an
48 answer I simply was not not comfortable with to the "Am I comfortable
49 enough with my setup to be reasonably sure I can recover it without fat-
50 fingering and breaking it instead, under the far higher stresses of a
51 recovery situation?" question.
52
53 USE="-static -static-libs", no package.use exceptions for them.
54
55 So what sort of static binaries am I running (other than the pre-packaged
56 grub-static as already mentioned), and are they really necessarily so?
57
58 >> I'm following the _original_ *nix idea of keeping it simple.
59 >
60 > you're confusing the notion of tradeoffs. the amount of tooling that
61 > shared libraries take to work at all let alone being stable is
62 > significantly higher than a single static binary.
63
64 Point well taken. There are indeed tradeoffs.
65
66 I'm choosing ease of administration and a second root image, partly in a
67 deliberate attempt to avoid unnecessarily increasing my chance of fat-
68 fingering a recovery, over the rather more straightforward for the
69 computer, but significantly more complex for the admin, static linking
70 and limited recovery tools strategy. I guess I trust that the computer
71 side, once a backup is tested and found to work, is far more reliable
72 than the human/admin side under stressful-for-humans recovery scenarios,
73 so am deliberately choosing my tradeoffs.
74
75 --
76 Duncan - List replies preferred. No HTML msgs.
77 "Every nonfree program has a lord, a master --
78 and if you use the program, he is your master." Richard Stallman

Replies