[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RES: /usr/lib vs /usr/libexec

Hash: SHA1

Russ Allbery <rra@stanford.edu> writes:

> Thomas Bushnell BSG <tb@becket.net> writes:
>> I do believe you've missed the point.  Splitting /usr from / helps in a
>> teeny percentage of cases, and most of the cases where it "helps" that
>> have been mentioned here, it actually doesn't.  Yet, splitting /usr/lib,
>> which is grotesquely huge and hard to deal with, is treated as an
>> impossible thing, needing a great level of proof before it can be
>> considered.  This is very foolish.
> The difference being that Debian has already split /usr from / and
> therefore is only paying the marginal cost of maintaining it, whereas
> Debian has not split /usr/lib from /usr/libexec and would have to pay the
> (far larger) initial cost of moving everything around.

Not really, since in many cases libexec was /already the default/.  In
these cases we are deliberately diverging from upstream, and so we
would be removing extra patches and customisations from our diffs.

Additionally, the migration is not difficult, and can be done over an
extended period.  It's not like I want a flag day when we must all
convert, I just want the option of using it.

The only reason we don't have it is FHS infighting, otherwise we would
have been using it eight years ago.  I don't consider that a good
reason to ignore it.

> I think it's quite reasonable for that far larger initial cost to require
> substantial justification, far more justification than is required for
> preserving a property that Debian has already paid the cost to establish
> and is just maintaining.

We've paid the price by shoving every bit of uncategorised junk into
one big festering sore: /usr/lib.  Making it a little tidier by
categorising some of its contents slightly differently is not a bad

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>


Reply to: