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: Vlad Glagolev <stealth AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] /usr merge
  • Date: Wed, 15 Feb 2012 17:21:14 +0400

You know my opinion on this,

I've forbidden this going into test recently by many reasons.

I can't agree with David fully, but since I know he's a great systemd
lover and uses virtualization so much (though according to
79ff8c05553e72d14da0c7bdeb7c1718cc40e503 he doesn't :D) I can
understand his position, and it's partially correct.

Look, one of our most powerful sides is flexibility. We try to provide
as many features and options to the end-user as possible (sometimes
even when they're not supported by upstream already). So let's focus on
what we do our best.

But new idea about /usr merging fails to conform FHS [0], [1]. And I'm
pretty sure such change will never be accepted globally as it breaks
very essential things on top of UNIX/UNIX-like basis.

This is somehow BSD systems (though not those becoming Linux-like
BSDs :) are more stable in some areas than 99% of Linux distros.
Cause I know how the code is written for such kernels, when every
f***ing time it breaks half of the system besides adding some shiny
feature :) But yes.. they're not like in 90th of development...

Our goal is to find a compromise between stability and the number of
features we'd like to support.

* First of all, like Andraž mentioned, we need to create provider for
kmod and module-init-tools.
* Second, create the 2nd branch for udev, since in my opinion we still
need to provide old kernel selection (like 2.6.27 and even from 2.4
branch) along with new software out of the box.
* And finally make it all work, creating required workarounds from
switching between these 2 approaches easily (making default as
non-/usr-merging one).

All these steps must be done in a branch.
Once it's ready -- it can go into test passing hard tests by several
people, then -- into stable.

I take position for providing a choice.

[0] http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs
[1] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

On Tue Feb 7 05:16:01 EST 2012
Ladislav Hagara <ladislav.hagara AT unob.cz> wrote:

> 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

--
Dont wait to die to find paradise...
--
Cheerz,
Vlad "Stealth" Glagolev

Attachment: pgpDY1jjP0Yi7.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page