sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: David Kowis <dkowis AT shlrm.org>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] /usr merge
- Date: Tue, 07 Feb 2012 10:31:12 -0600
On 02/07/2012 04:33 AM, flux wrote:
> Ladislav Hagara (ladislav.hagara AT unob.cz) wrote [12.02.07 19:16]:
>> Hi,
>>
>> any plan with /usr merge [1]?
>> Personally I don't like it but I am a realist. We have no chance to
>> change the upstream.
>> New versions of crucial upstream packages rely on /usr merge.
>> Do we want to use devel-udev-kmod git branch by the same way as
>> devel-xorg-modular or we plan to integrate it soon?
>>
>> [1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
>
> <cents value="2">
>
> This is not all upstream, only for some projects. I doubt this will ever
> become a common standard, as it would actually break many setups in
> which it is very legitimate to have the separated. I'm not going to go
> into the arguments, but pushing everything into /usr can only be viable
> on desktop end-user systems, and is a purely bad idea in server
> environments. Even on desktop systems, if the /usr partition isn't large
> enough to accomodate everything else (unlikely, but possible), then it
> can even break existing desktop environments. If someone really wants a
> merged setup, pushing everything to / when there is only a single
> partition for the whole disk is much better than pushing it to /usr
> IMHO.
The article covers the most common use cases for a network mounted or a
read-only /usr.
It's not a bad idea in server environments either, since it really only
matters at boot time. Once the file systems are established and in
place, you're all set.
The advantage of using it in virtualized environments to share a
read-only /usr among many guest VMs could be significant.
>
> At any rate, we supposedly follow FHS, and as long as this isn't in FHS,
> those upstreams actually violate the higher-up policy (note: many
> upstreams install to /usr/local by default, and we modify those, so
> there are many existing cases where FHS trumps specific upstream in our
> distro). In other words, unless/until there is very widespread
> acceptance of this, I don't see a reason for us to adhere to it. I
> definitely don't want this for my own systems.
I think that's a reasonable course of action at this time. Keep an eye
on it, and evaluate it as it becomes appropriate to.
David
Attachment:
signature.asc
Description: OpenPGP digital signature
-
[SM-Discuss] /usr merge,
Ladislav Hagara, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
flux, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
David Kowis, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
flux, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
Sukneet Basuta, 02/07/2012
- Re: [SM-Discuss] /usr merge, flux, 02/08/2012
- Re: [SM-Discuss] /usr merge, Ismael Luceno, 02/26/2012
-
Re: [SM-Discuss] /usr merge,
Sukneet Basuta, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
flux, 02/07/2012
- Re: [SM-Discuss] /usr merge, Ismael Luceno, 02/26/2012
-
Re: [SM-Discuss] /usr merge,
David Kowis, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
Andraž 'ruskie' Levstik, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
Jaka Kranjc, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
Robin Cook, 02/07/2012
- Re: [SM-Discuss] /usr merge, flux, 02/07/2012
- Re: [SM-Discuss] /usr merge, Jaka Kranjc, 02/08/2012
-
Re: [SM-Discuss] /usr merge,
Robin Cook, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
Jaka Kranjc, 02/07/2012
-
Re: [SM-Discuss] /usr merge,
flux, 02/07/2012
Archive powered by MHonArc 2.6.24.