Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] /usr merge

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • 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




Archive powered by MHonArc 2.6.24.

Top of Page