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
In Reply to: Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary by Mike Frysinger
Mike Frysinger posted on Mon, 19 Sep 2011 12:05:39 -0400 as excerpted:

> On Monday, September 19, 2011 11:35:09 Michał Górny wrote: >> On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote: >> > > > by that token, i'll go ahead and remove glibc's static libraries >> > > > since upstream doesn't even support static linking >> > > >> > > I'm probably ignorant so you'd have to elaborate more on that to >> > > make me see a problem there. >> > >> > think about it a little bit. your system is using static binaries >> > right now, and considering you like to push systemd + initramfs so >> > much, i would have thought you'd realize the implications more >> > quickly. >> >> Hm, I seem to fail to notice other static binaries than busybox. And I >> don't think I use any specific configuration which makes me need static >> binaries; > > by default, tools that are needed to easily recover a system > (busybox/cryptsetup/lvm/etc...) are IUSE=+static, and every binary that > goes into initramfs is statically linked.
By default? That's begging the question (logic sense) and consequently does not properly support your blanket "your system is using static binaries right now" statement. That doesn't mean the statement is incorrect. I may well be using static binaries of some sort, but I'm not aware of any (save for grub-static, since I run amd64/no-multilib), and I'd love to know more about which binaries they are, and whether static linking is really necessary for them. Feel free to post a link as I've a feeling this is reasonably basic, but evidently I'm not the only one who would find such info educational and likely useful. FWIW, no busybox here. It wouldn't build when I installed back in 2004, so I package.provided it for later. I tried it again a couple times but by then it was quite clear that it really was NOT needed, so eventually I decided I had better things to do than tilt at that windmill. (I use a second root image, updated AND TESTED when the system appears to be working well, as my emergency recovery solution, thus don't need busybox.) I run (partitioned) md/raid because I can feed appropriate assemble instructions on the kernel command line, no initr* needed. I do NOT use lvm because it would require either an initr* for the root and root- backup images or keeping them separate, needlessly increasing complexity now that md/raid handles partitions transparently, and triggering an answer I simply was not not comfortable with to the "Am I comfortable enough with my setup to be reasonably sure I can recover it without fat- fingering and breaking it instead, under the far higher stresses of a recovery situation?" question. USE="-static -static-libs", no package.use exceptions for them. So what sort of static binaries am I running (other than the pre-packaged grub-static as already mentioned), and are they really necessarily so?
>> I'm following the _original_ *nix idea of keeping it simple. > > you're confusing the notion of tradeoffs. the amount of tooling that > shared libraries take to work at all let alone being stable is > significantly higher than a single static binary.
Point well taken. There are indeed tradeoffs. I'm choosing ease of administration and a second root image, partly in a deliberate attempt to avoid unnecessarily increasing my chance of fat- fingering a recovery, over the rather more straightforward for the computer, but significantly more complex for the admin, static linking and limited recovery tools strategy. I guess I trust that the computer side, once a backup is tested and found to work, is far more reliable than the human/admin side under stressful-for-humans recovery scenarios, so am deliberately choosing my tradeoffs. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman