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-17-2012, 09:20 PM
Richard Yao
 
Default Opinion against /usr merge

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.

Interestingly, the /usr merge changes made to genkernel permit us to
mount /etc from a genkernel-built initramfs by putting /etc on a
separate mount point in fstab and then doing `echo /etc >>
/etc/initramfs.mounts`.

Some people claim that the current approach is somehow broken by citing
Bluetooth keyboards. However, what makes that work is adopting an
initramfs and that does *not* require moving files into /usr. If people
do not want an initramfs, they can simply not have a separate /usr. The
/usr merge gives nothing to people using bluetooth while the /usr merge
will break systems of non-bluetooth users.

I have been told that moving everything into /usr would be easy for us
because Arch Linux did it and they are a rolling distribution too. Arch
Linux does all-or-nothing upgrades. They do not offer the ability for
their users to choose to use older versions of software and we will not
be able to move everything into /usr without breaking existing systems
that boot without issues now.

I have also been told that the /usr merge is necessary because upstream
will force it on us. Interestingly, most of @system on Gentoo Linux is
GNU software, which would need to stop supporting things in / in order
for that to happen. As far ass I know, systemd does not work on GNU HURD
and it would be incapable of functioning if the GNU project made this
change. Hell will freeze long before that happens.

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.

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?

Lastly, don't tell me to read systemd's case for why we should break
people's systems. I have read it and I find it flawed. There is
absolutely no need for us to make this change.

Yours truly,
Richard Yao
 
Old 07-17-2012, 10:41 PM
Rich Freeman
 
Default Opinion against /usr merge

On Tue, Jul 17, 2012 at 5:20 PM, Richard Yao <ryao@gentoo.org> wrote:
> I have also been told that the /usr merge is necessary because upstream
> will force it on us. Interestingly, most of @system on Gentoo Linux is
> GNU software, which would need to stop supporting things in / in order
> for that to happen.

I don't think anybody in Gentoo is advocating a full /usr merge. I
think that the only thing that has been happening is that there will
not be any heroic measures to keep a system with a separate /usr
booting without the use of an initramfs or some early-running script.

It doesn't matter that the majority of @system software is GNU. For a
separate /usr to not work does not require ALL of the software to not
support it, but only for a few pieces of software to not support it -
a chain is as strong as its weakest link.

In any case, it sounds like for now some devs are continuing to adjust
ebuilds to keep a separate /usr working as well as possible, though it
apparently breaks in some edge cases right now without an initramfs,
as you've already noted in your email.

I don't think anybody in Gentoo is really pushing for a /usr merge -
there are just lots of devs saying that they aren't going to spend a
lot of time stopping it either. If upstream sticks files needed to
boot in /usr then it is basically up to somebody who cares to do
something to move them. Right now that isn't a lot of work, but the
reason people are concerned is that this is likely to change.

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.

Rich
 
Old 07-17-2012, 11:02 PM
William Hubbs
 
Default Opinion against /usr merge

On Tue, Jul 17, 2012 at 05:20:13PM -0400, Richard Yao 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.

This is not quite correct. The initramfs is required because of [1].

> Interestingly, the /usr merge changes made to genkernel permit us to
> mount /etc from a genkernel-built initramfs by putting /etc on a
> separate mount point in fstab and then doing `echo /etc >>
> /etc/initramfs.mounts`.

That doesn't negate putting /usr on nfs and making it possible for
different hosts to share it.

> Some people claim that the current approach is somehow broken by citing
> Bluetooth keyboards. However, what makes that work is adopting an
> initramfs and that does *not* require moving files into /usr. If people
> do not want an initramfs, they can simply not have a separate /usr. The
> /usr merge gives nothing to people using bluetooth while the /usr merge
> will break systems of non-bluetooth users.

I don't see what bluetooth has to do with anything other than with the
'separate usr is broken' document which is a separate issue.

> I have been told that moving everything into /usr would be easy for us
> because Arch Linux did it and they are a rolling distribution too. Arch
> Linux does all-or-nothing upgrades. They do not offer the ability for
> their users to choose to use older versions of software and we will not
> be able to move everything into /usr without breaking existing systems
> that boot without issues now.

This issue is not completely flushed out with the upstream folks for
udev yet, and either way, it will be addressed in our version of udev.

> I have also been told that the /usr merge is necessary because upstream
> will force it on us. Interestingly, most of @system on Gentoo Linux is
> GNU software, which would need to stop supporting things in / in order
> for that to happen. As far ass I know, systemd does not work on GNU HURD
> and it would be incapable of functioning if the GNU project made this
> change. Hell will freeze long before that happens.

This is basically not relevant since we do not support HURD.

> 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.

We offer several rc systems in the tree, but I don't know how up to
date they are. Either way, bringing back bl1 is not a relevant
argument, because it is not compatible with OpenRC.

> 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?

I think we can do the /usr merge in a way that won't break systems; I am
looking into that possibility. I am not interested in breaking systems.

> Lastly, don't tell me to read systemd's case for why we should break
> people's systems. I have read it and I find it flawed. There is
> absolutely no need for us to make this change.

Without elaboration on why you find their case flawed, this sounds
like the typical, "if it isn't broke, don't fix it" argument.
While that has merrit, if there are advantages to doing
something, like I think there would be to doing the /usr merge, it may
be worth the transition, especially if we can make it as smooth as
possible.

William
 
Old 07-17-2012, 11:07 PM
Olivier Crête
 
Default Opinion against /usr merge

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.

--
Olivier Crête
tester@gentoo.org
Gentoo Developer
 
Old 07-17-2012, 11:13 PM
Dale
 
Default Opinion against /usr merge

William Hubbs wrote:
>
> This is not quite correct. The initramfs is required because of [1].
>
>
> William
>

Where is [1]?

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
 
Old 07-17-2012, 11:19 PM
William Hubbs
 
Default Opinion against /usr merge

On Tue, Jul 17, 2012 at 06:41:26PM -0400, Rich Freeman wrote:
> In any case, it sounds like for now some devs are continuing to adjust
> ebuilds to keep a separate /usr working as well as possible, though it
> apparently breaks in some edge cases right now without an initramfs,
> as you've already noted in your email.
>
> I don't think anybody in Gentoo is really pushing for a /usr merge -
> there are just lots of devs saying that they aren't going to spend a
> lot of time stopping it either. If upstream sticks files needed to
> boot in /usr then it is basically up to somebody who cares to do
> something to move them. Right now that isn't a lot of work, but the
> reason people are concerned is that this is likely to change.

Right, I'm definitely not advocating a full out /usr merge tomorrow or
anything, I am just not interested in doing a whole lot of patching to
keep something from moving to /usr if upstream moves it there.

Also, I am interested in looking at what is installed in /, and if
upstream defaults put it in /usr, allowing it to happen on gentoo that
way as well.

My thought is that eventually we will have more and more things that are
being installed in /usr.

> 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.

Right, that's the issue. Some upstreams (mainly udev) have dropped
backward compatibility. But, I will be able to get around those for a
while.

William
 
Old 07-17-2012, 11:19 PM
Richard Yao
 
Default Opinion against /usr merge

On 07/17/2012 07:02 PM, William Hubbs wrote:
> On Tue, Jul 17, 2012 at 05:20:13PM -0400, Richard Yao 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.
>
> This is not quite correct. The initramfs is required because of [1].

What is [1]?

>> Interestingly, the /usr merge changes made to genkernel permit us to
>> mount /etc from a genkernel-built initramfs by putting /etc on a
>> separate mount point in fstab and then doing `echo /etc >>
>> /etc/initramfs.mounts`.
>
> That doesn't negate putting /usr on nfs and making it possible for
> different hosts to share it.

People can still have different hosts share / with host-specific stuff
(e.g. /etc) mounted by genkernel.

>> I have also been told that the /usr merge is necessary because upstream
>> will force it on us. Interestingly, most of @system on Gentoo Linux is
>> GNU software, which would need to stop supporting things in / in order
>> for that to happen. As far ass I know, systemd does not work on GNU HURD
>> and it would be incapable of functioning if the GNU project made this
>> change. Hell will freeze long before that happens.
>
> This is basically not relevant since we do not support HURD.

It is relevant because it guarantees that the GNU stuff in @system will
continue working. That allows us to narrow our focus to the non-GNU
things required to use Gentoo Linux.

Looking at @system and what it typically pulls into @world, the only
thing that might cause a problem is udev, although virtual/dev-manager
is in @system, rather than udev. If that happens, we have a few ways of
dealing with that:

1. Patch udev.
2. Fork udev.
3. Consider breaking people's systems then.

Until then, doing what RedHat wants is unnecessary.

>> Lastly, don't tell me to read systemd's case for why we should break
>> people's systems. I have read it and I find it flawed. There is
>> absolutely no need for us to make this change.
>
> Without elaboration on why you find their case flawed, this sounds
> like the typical, "if it isn't broke, don't fix it" argument.
> While that has merrit, if there are advantages to doing
> something, like I think there would be to doing the /usr merge, it may
> be worth the transition, especially if we can make it as smooth as
> possible.

The cost to benefit ratio is simply too low for "lets change it because
it could be better this way" to merit making the change. The things that
I have heard are going to break existing systems that I have gone
through some trouble to support. I really don't want to see that.
 
Old 07-17-2012, 11:23 PM
William Hubbs
 
Default Opinion against /usr merge

On Tue, Jul 17, 2012 at 06:13:06PM -0500, Dale wrote:
>
> William Hubbs wrote:
> >
> > This is not quite correct. The initramfs is required because of [1].
> >
> >
> > William
> >
>
> Where is [1]?

[1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

We have a way around this in some limited circumstances with
busybox[sep-usr], but that definitely does not support anything fancy
like rade, lvm, etc.

William
 
Old 07-17-2012, 11:46 PM
Dale
 
Default Opinion against /usr merge

William Hubbs wrote:
> On Tue, Jul 17, 2012 at 06:13:06PM -0500, Dale wrote:
>> William Hubbs wrote:
>>>
>>> This is not quite correct. The initramfs is required because of [1].
>>>
>>>
>>> William
>>>
>> Where is [1]?
> [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> We have a way around this in some limited circumstances with
> busybox[sep-usr], but that definitely does not support anything fancy
> like rade, lvm, etc.
>
> William
>


Ah, read that link a while back. Nothing new there I don't guess.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
 
Old 07-18-2012, 12:12 AM
William Hubbs
 
Default Opinion against /usr merge

On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote:
> On 07/17/2012 07:02 PM, William Hubbs wrote:
> > This is basically not relevant since we do not support HURD.
>
> It is relevant because it guarantees that the GNU stuff in @system will
> continue working. That allows us to narrow our focus to the non-GNU
> things required to use Gentoo Linux.
>
> Looking at @system and what it typically pulls into @world, the only
> thing that might cause a problem is udev, although virtual/dev-manager
> is in @system, rather than udev. If that happens, we have a few ways of
> dealing with that:
>
> 1. Patch udev.

I think I can come up with a patch locally that will read rules from
/lib/udev/rules.d if that's what we want to do for now.

> 2. Fork udev.

I don't think this is necessary, and it would create more work for us
than is needed.

> >> Lastly, don't tell me to read systemd's case for why we should break
> >> people's systems. I have read it and I find it flawed. There is
> >> absolutely no need for us to make this change.
> >
> > Without elaboration on why you find their case flawed, this sounds
> > like the typical, "if it isn't broke, don't fix it" argument.
> > While that has merrit, if there are advantages to doing
> > something, like I think there would be to doing the /usr merge, it may
> > be worth the transition, especially if we can make it as smooth as
> > possible.
>
> The cost to benefit ratio is simply too low for "lets change it because
> it could be better this way" to merit making the change. The things that
> I have heard are going to break existing systems that I have gone
> through some trouble to support. I really don't want to see that.

You are still not saying what things you have heard. Your concerns can't
be addressed if you don't tell us what they are.

William
 

Thread Tools




All times are GMT. The time now is 12:40 AM.

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