FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-18-2012, 04:37 AM
Duncan
 
Default Opinion against /usr merge

Richard Yao posted on Tue, 17 Jul 2012 17:20:13 -0400 as excerpted:

> The only thing that might require a merge is systemd and it is not in
> @system. If we offered users the ability to choose rc systems, we would
> still be supporting baselayout-1's rc system. If we start now, we should
> bring that back.

Just addressing this little bit.

The first and primary requirement for gentoo support of any rc/init
system is that there's someone (gentoo dev or not, but baselayout was
gentoo based so gentoo dev, or at least an advanced gentoo user, would be
most likely) interested in maintaining it as upstream, and a gentoo dev
(can be the same person) interested in maintaining the gentoo package/
ebuild. Gentoo's a community distro build on FLOSS, and if nobody's
interested in assuming that work/responsibility for either gentoo or as
upstream, ultimately, it gets tree-cleaned.

Think about it.


Consider things like kde3 and the kde-sunset overlay, too. That's not
system init, but you're likely talking a job of similar size to continue
to support it, with all the necessary initscripts, etc. kde-sunset is
what happens when there's sufficiently interested users but no
sufficiently interested gentoo devs, and/or a break in upstream
maintainership (tho it eventually continued via the trinity project).


Other (not even officially supported) init systems such as systemd that
happen to be in our tree have at least that required minimum, and remain
in the tree. kde3, despite having an active remaining gentoo userbase
that continues to maintain it to some degree, didn't have that minimum.

But I can say this. If there had been a sufficient level of gentoo
developer interest in maintaining kde3 in-tree, it would have happened.
Where there's developer interest, the product says around. There simply
weren't developers stepping up to maintain it, so it ended up in an
overlay.


The same thing applies to baselayout-1... and for that matter,
baselayout-2/openrc. If there had been sufficient developer interest in
maintaining a working baselayout-1, it would have happened. Without it,
no arbitrary ruling, no "if systemd, then baselayout-1", no "thus saith
the council", will change it.

Similarly, no wishing, "should be"s, decrees from council, etc, got
baselayout-2/openrc stabilized, until williamh volunteered to push on it
(certainly with help from others, but it didn't happen until someone
stepped up to take personal responsibility for ensuring that it WOULD
happen) until it got done.


What you're seeing here with the unified / and /usr idea is more or less
a similar dynamic, tho to quite a lessor extent. Upstreams are making
their choices, and the gentoo maintainers of the corresponding packages
are making /their/ choices. That's all there is to it. Upstream's going
its way, but regardless of that, if there's sufficient interest among
gentoo devs to guarantee patch development, testing, deployment, further
testing, stabilization, and bug followup, gentoo WILL continue to make an
initr*-less separate /usr work.

But one of the things that had (at least until recently, I've seen
arguments that it's breaking down now, with android, ubuntu, etc, going
their own way to a greater extent than most before, and android
especially is big enough to pull it off!) kept Linux from fragmenting the
way the old Unices did was that while FLOSS ALLOWS forking, it also
provides significant pressure to ONLY fork where one REALLY feels it's a
high priority deal. Otherwise, it's simply less work and less expense,
to go with upstream. That's why we have all these distributions, each
generally different in their own way (and gentoo's certainly rather
different from the generally binary distros, for sure!), but except for
the features that a particular distro is emphasizing, that it thinks are
important enough to be worth the trouble of maintaining that
differentiation, it tends to stay pretty close to mainline.


Which again, is exactly the dynamic we're seeing here. What we're going
thru right now, with all the threads and discussion related to this, is
simply debating whether, as a distro, gentoo considers this
differentiation from upstream worth the cost of continued maintenance.
Which is where the point I made above comes in. If there's no gentoo
devs caring enough to make it their job to ensure that support remains,
the default will simply be to follow upstream, only maintaining the
minimal patches necessary to continue what gentoo, individually and
collectively, finds high enough priority to be worth the time and effort
cost to maintain the differentiation.

And as of now, just as with kde3, the fact of the matter is that despite
a decent level of interest from users, it doesn't look like we have the
necessary interest from devs to commit to such support, long-term. What
we're seeing is devs committing to maintaining support for the short and
intermediate (?) future, out perhaps six months to a year or two, but the
differentiation cost trend beyond that looks to increase quite
dramatically, and at least at present, we don't have enough developers
willing to commit to maintaining it beyond that.


And the thing is, no "should"s are going to change that. If you (and
other users, personally I'm in the middle, interested but not caring
enough to really commit to it) want it, there's two ways to get it:

1) Start now, and either convince enough current devs or convince to join
enough new devs, so when the time comes, that commitment can be made,
even if it means a significantly increased patch load, to the point of de-
facto or official forking.

2) Get ready for a user-managed overlay, similar to kde-sunset.

Of course the other alternative would be to find a distro more suitable,
but for a lot of gentooers, that's not an alternative they consider
viable, as gentoo's close enough to what they want that there really
/aren't/ a lot of distros even /close/ to suitable, let alone /more/ so.
Of course, both users and distros change over time, and a lot can happen
in two years, but...

Then of course there's the "found your own distro" club... Something
gentoo's founder, Daniel Robbins, has done more than once, now... But of
course just as his current gentoo-based funtoo (and other gentoo-based
distros, after all, gentoo even claims meta-distro, so gentoo-based distro
fits right in!), just because you do your own thing doesn't mean you
can't base on gentoo to whatever degree you want/need, as long as you
maintain compatible licensing and at least semi-compatible package-
management.

--
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
 
Old 07-18-2012, 04:37 AM
Olivier Cr阾e
 
Default Opinion against /usr merge

On Tue, 2012-07-17 at 23:54 -0400, Richard Yao wrote:
> On 07/17/2012 07:07 PM, Olivier Cr阾e wrote:
> > On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote:
> >> If somebody really is pushing for an all-out /usr move by all means
> >> speak up, but I think that basically what everybody is advocating is
> >> trying to follow upstream for individual packages.
> >
> > As I've been saying for a while, doing a full merge of /bin, /sbin, /lib
> > into /usr is probably unavoidable in the long term. We should be ready
> > for it, and even try to do it progressively. As currently, the split is
> > entirely arbitrary.
> >
> > Also be ready for a merge of /bin and /sbin.. I'm sure most people can't
> > even explain the difference between them.
> >
>
> The difference is simple. You put stuff into /sbin when you do not want
> regular users to be able to select it via tab completion by default.

That's certainly not how te FHS explains it.

--
Olivier Cr阾e
tester@gentoo.org
Gentoo Developer
 
Old 07-18-2012, 04:42 AM
Olivier Cr阾e
 
Default Opinion against /usr merge

On Tue, 2012-07-17 at 23:24 -0400, Richard Yao wrote:
> GNOME is part of the GNU project, so we should be safe unless they
> decide against portability. OpenSuSe and Mageia are other distributions,
> so they are not upstream for us.

With my GNOME hat on:

GNOME does not take any marching orders from RMS or anyone else in the
GNU project. We will do any changes that we believe are necessary to
produce a better end user experience or to make our code more
maintainable. If that means adding dependencies that are Linux specific,
we will do it. And we have done it before, for example, we have
dependencies on udev for certain features.

--
Olivier Cr阾e
tester@gentoo.org
Gentoo Developer
 
Old 07-18-2012, 07:41 AM
Micha艂 G贸rny
 
Default Opinion against /usr merge

On Tue, 17 Jul 2012 17:20:13 -0400
Richard Yao <ryao@gentoo.org> wrote:

> An often cited benefit of the /usr merge is the ability to put
> everything but /etc on NFS and for that reason, we need to force an
> initramfs on people happily using /usr without it.

Are you going to send a single mail for every single benefit I will add
to the wiki? :>

--
Best regards,
Micha艂 G贸rny
 
Old 07-18-2012, 08:10 AM
Micha艂 G贸rny
 
Default Opinion against /usr merge

On Tue, 17 Jul 2012 23:54:16 -0400
Richard Yao <ryao@gentoo.org> wrote:

> On 07/17/2012 07:07 PM, Olivier Cr锚te wrote:
> > On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote:
> >> If somebody really is pushing for an all-out /usr move by all means
> >> speak up, but I think that basically what everybody is advocating
> >> is trying to follow upstream for individual packages.
> >
> > As I've been saying for a while, doing a full merge
> > of /bin, /sbin, /lib into /usr is probably unavoidable in the long
> > term. We should be ready for it, and even try to do it
> > progressively. As currently, the split is entirely arbitrary.
> >
> > Also be ready for a merge of /bin and /sbin.. I'm sure most people
> > can't even explain the difference between them.
> >
>
> The difference is simple. You put stuff into /sbin when you do not
> want regular users to be able to select it via tab completion by
> default.

Now put that definition into my cold logic brain.

--
Best regards,
Micha艂 G贸rny
 
Old 07-18-2012, 08:18 AM
Micha艂 G贸rny
 
Default Opinion against /usr merge

On Tue, 17 Jul 2012 17:20:13 -0400
Richard Yao <ryao@gentoo.org> wrote:

> Dear Everyone,
>
> An often cited benefit of the /usr merge is the ability to put
> everything but /etc on NFS and for that reason, we need to force an
> initramfs on people happily using /usr without it.

You forgot about /var. And possibly /srv. But yes, you are probably
having separate filesystems so you don't care about people having
different layout.

> With that said, there is a great deal of FUD being spread by the
> systemd developers and I see no reason for us to accept it. We would
> be breaking users' systems for no gain other than to make the systemd
> developers happy. Their refusal to permit udev to be built separately
> from systemd demonstrated complete disdain for Gentoo Linux. Why
> should we let them dictate how we design our distribution at our
> users' expense?

Didn't you see Lennart's opinions on Gentoo Linux? I don't think their
refusal needed to be expressed at all.

--
Best regards,
Micha艂 G贸rny
 
Old 07-18-2012, 09:49 AM
Duncan
 
Default Opinion against /usr merge

Micha艂 G贸rny posted on Wed, 18 Jul 2012 10:18:49 +0200 as excerpted:

> Didn't you see Lennart's opinions on Gentoo Linux? I don't think their
> refusal needed to be expressed at all.

I don't believe I did. Link?

(FWIW I expect I'll eventually switch to systemd, but there's no hurry,
and IMO it has some maturing to do still. Meanwhile, openrc's working
great for me ATM and I have no immediate plans to switch.)

--
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
 
Old 07-18-2012, 09:55 AM
Micha艂 G贸rny
 
Default Opinion against /usr merge

On Wed, 18 Jul 2012 09:49:24 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Micha艂 G贸rny posted on Wed, 18 Jul 2012 10:18:49 +0200 as excerpted:
>
> > Didn't you see Lennart's opinions on Gentoo Linux? I don't think
> > their refusal needed to be expressed at all.
>
> I don't believe I did. Link?

http://lalists.stanford.edu/lad/2009/06/0191.html

Around the non-wrapped line.

--
Best regards,
Micha艂 G贸rny
 
Old 07-18-2012, 10:44 AM
Duncan
 
Default Opinion against /usr merge

Micha艂 G贸rny posted on Wed, 18 Jul 2012 11:55:32 +0200 as excerpted:

> On Wed, 18 Jul 2012 09:49:24 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>> Micha艂 G贸rny posted on Wed, 18 Jul 2012 10:18:49 +0200 as excerpted:
>>
>> > Didn't you see Lennart's opinions on Gentoo Linux? I don't think
>> > their refusal needed to be expressed at all.
>>
>> I don't believe I did. Link?
>
> http://lalists.stanford.edu/lad/2009/06/0191.html
>
> Around the non-wrapped line.

Thanks. Not too surprising for a major binary-distro dev, I guess.

Meanwhile, I'm more appreciative than ever of gentoo's abilities. Where
else would I be able to run a fully distro-supported kde, without all the
kde semantic-desktop stuff dragging stuff down? Turning it off at
runtime didn't cut it, but killing it at build-time surely did! =:^)

That's an option people running most distros won't ever have; a contrast
they'll never be able to make, at least not without a whole lot more
manual fiddling than necessary on gentoo, anyway.

Makes me really appreciate what we have, here on gentoo.

--
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
 
Old 07-18-2012, 01:18 PM
Richard Yao
 
Default Opinion against /usr merge

On 07/18/2012 04:10 AM, Micha艂 G贸rny wrote:
> On Tue, 17 Jul 2012 23:54:16 -0400
> Richard Yao <ryao@gentoo.org> wrote:
>
>> On 07/17/2012 07:07 PM, Olivier Cr锚te wrote:
>>> On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote:
>>>> If somebody really is pushing for an all-out /usr move by all means
>>>> speak up, but I think that basically what everybody is advocating
>>>> is trying to follow upstream for individual packages.
>>>
>>> As I've been saying for a while, doing a full merge
>>> of /bin, /sbin, /lib into /usr is probably unavoidable in the long
>>> term. We should be ready for it, and even try to do it
>>> progressively. As currently, the split is entirely arbitrary.
>>>
>>> Also be ready for a merge of /bin and /sbin.. I'm sure most people
>>> can't even explain the difference between them.
>>>
>>
>> The difference is simple. You put stuff into /sbin when you do not
>> want regular users to be able to select it via tab completion by
>> default.
>
> Now put that definition into my cold logic brain.
>

That was meant as a joke, although the irony is that it is true.
 

Thread Tools




All times are GMT. The time now is 07:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org