Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: Please don't use IUSE=static-libs unless really necessary
Date: Mon, 19 Sep 2011 22:25:36 +0000 (UTC)
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



Replies:
Re: Re: Please don't use IUSE=static-libs unless really necessary
-- Mike Frysinger
References:
Please don't use IUSE=static-libs unless really necessary
-- Michał Górny
Re: Please don't use IUSE=static-libs unless really necessary
-- Mike Frysinger
Re: Please don't use IUSE=static-libs unless really necessary
-- Michał Górny
Re: Please don't use IUSE=static-libs unless really necessary
-- Mike Frysinger
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Please don't use IUSE=static-libs unless really necessary
Next by thread:
Re: Re: Please don't use IUSE=static-libs unless really necessary
Previous by date:
RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by date:
Re: udev and /usr


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.