Re: [gentoo-dev] Re: eudev project announcement

["J. Roeleveld" <joost@antarean.org>]

[-- Attachment #1: Type: text/plain, Size: 8044 bytes --]

On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote:
> On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote:
> > On Mon, December 17, 2012 22:31, Greg KH wrote:
> > > On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
> > >> Olav Vitters <olav@vitters.nl> wrote:
> > >> >On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
> > >> >> As I said in an earlier email, Lennart Poettering claims that it
> > >> >> does
> > >> >> not work. We are discussing some of the things necessary to make it
> > >> >
> > >> >work.
> > >> >
> > >> >Just to repeat:
> > >> >In this thread it was claimed that a separate /usr is not supported by
> > >> >systemd/udev.
> > >> >
> > >> >A case which works with latest systemd on various distributions. I
> > >> >checked with upstream (not Lennart), and they confirmed it works. I
> > >> >can
> > >> >wait for Lennart to say the same, but really not needed.
> > >> >
> > >> >I assume this will again turn into a "but I meant something else".
> > >> 
> > >> Olav.
> > >> 
> > >> Lennart has stated that he considers a seperate /usr without init*
> > >> broken.
> > > 
> > > Yes, as do I, and so do a lot of other developers.
> > 
> > It is only "broken", because upstream decided to move everything into /usr
> > that was previously in /.
> 
> No, not at all, please see the web page that describes, in detail, the
> problems that has been going on for quite some time now, with the /usr
> and / partitions and packages.
> 	http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> 
> One good solution to this issue is to move everything into /usr, and
> that's something that has wonderful benifits in the long run, and is
> something that I expect all Linux distros to eventually implement.
> Those that don't, will suffer because of it.
> 
> Again, see the web page for why moving stuff into /usr is a good idea
> for the reasons behind this.
> 	http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

Example: /usr Network Share
When /usr is on a network share, why not add a / on network as well?
I have multiple systems and as they all have different uses, they all have 
different software installed.

Example: Multiple Guest Operating Systems on the Same Host
See answer to previous example.

How many environments actually currently exist where a shared /usr is being 
used?

> > >> This has worked correctly in the past.
> > > 
> > > Define "past" please.
> > 
> > Recent past, like a few months ago no errors during boot and the system
> > running stable.
> 
> You have gotten lucky, see the above links for why.

ALSA, LVM and HPLIP work perfectly with /usr on LVM without an initramfs.
I have sound, the LVM partitions are detected and mounted correctly and I can 
use the full functionality of any HP printer I get access to.
Those three are listed as being broken.
 
> > Please provide a simple way to let me see that it is broken on systems
> > that do not use bluetooth keyboards.
> 
> Again, see the above link for how to do this.

See above, 3 items that I use daily (apart from hplip, don't need printing and 
scanner daily) are listed as broken, but work without error.
In what way should they be broken and how can I find out?

> > The requirement of having userspace working to have input devices working
> > seems to be related to bluetooth, not to USB or PS/2 keyboards.
> 
> Not at all, see the above link.

Ok, a few other devices are mentioned, the only one I need to mount /usr in 
that list is LVM, which starts correctly already.

> > And using a bluetooth connection to access a NFS share is, in my humble
> > opinion, a corner case that requires additional work to make it work.
> 
> One person's "corner case" is another person's default operating mode.

Yes, but the "corner case" I just mentioned is one that won't work without a 
init*. My use-case has been stable for years.

> > > Note, it's still broken, I have yet to see any upstream fixes to resolve
> > > all of the issues that are involved here with "fixing" this up.
> > 
> > Reverting back to an older version makes it work.
> 
> Because of how we package udev?

If it's packaging, then why are we having this discussion and do we need a 
fork to fix udev?

> > Using "mdev" also works.
> 
> mdev is not recommended for desktop or server systems, but feel free to
> use it if you want.

I might not be recommended, but it does proof that a seperate /usr is not 
broken. The way udev doesn't handle it is.

> > > Yes, as always, for some subset of users, you can be lucky and it will
> > > work for them, but those systems are getting rarer and rarer these days,
> > > as the rest of upstream (not systemd here) are moving on and not doing
> > > anything to change their behavior for this topic.
> > 
> > Why rarer? Any system I can buy in a random shop will work using a
> > seperate /usr, provided the software is installed sanely.
> 
> Again, see above for why this is not true.

Only because udev-upstream declares such systems broken.

> > By moving everything into /usr, this brokenness is forced upon users.
> 
> Not at all, but that's a separate topic than what we are talking about
> here.

True, but that move is done by the same individual(s). (Based on the name at 
the bottom of both those pages you referenced)

> > >> The direction udev development is going, according to Lennart, is to
> > >> make that impossible and he refuses to fix this regression.
> > > 
> > > Again, this has NOTHING to do with udev or systemd, as has been pointed
> > > out numerous times.  I understand your _wish_ that it would have
> > > something to do with it, but that will not change the facts, sorry.
> > 
> > Then what does it have to do with?
> > When it was made public that it is considered "broken", the news came from
> > udev-upstream. This was before most systems encountered any breakage.
> 
> That is because things were failing silently for some people, and not so
> silently for others.  Now udev warns about this type of situation,
> shooting the messenger is usually a bad idea.

Not planning to shoot the messenger.
But when upstream takes the easy way out by declaring seperate /usr broken 
when that has been working correctly for years and then forcing additional 
parts onto peoples systems that they do not need or want will not be accepted 
with a smile.

> > >> I am really happy with this project and intend on testing it once
> > >> requests for this appear in the eudev mailing list.
> > > 
> > > Good luck, the root problems still remain, and nothing that eudev ever
> > > does can resolve that, sorry.
> > > 
> > > Can this topic finally be put to rest please?  There is a whole web page
> > > devoted to this topic, why do people blindly ignore it?
> > 
> > Where is this page?
> > I've read the page written by Lennart. Is there a decent (as in, going
> > into detail why it is broken and what it is caused by) analysis about the
> > "problem"?
> 
> See above for the links and the details.

Those I already read before.
These show the following timeline:
1) Lets move everything into /usr
2) Wait, with everything in /usr, we can't mount /usr. Lets declare a seperate 
/usr to be broken.
3) To solve 2, lets force everyone to use an init* that contains the stuff 
that should have stayed in /.

> > > Again, a separate /usr without an initrd has NOTHING to do with systemd
> > > or udev, with the minor exception that Gentoo's packaging of those
> > > programs _might_ have an issue, but that is Gentoo's issue, NOT
> > > upstream's issue.
> > > 
> > > If anyone involved with eudev, or is involved with the Gentoo Council
> > > thinks that the previous paragraph is incorrect, they are flat out
> > > wrong.
> > 
> > I have yet to hear about a clear explanation why a seperate /usr is broken
> > apart from the use of bluetooth keyboards. (Which are still in the
> > minority when I check local shops/webstores)
> 
> Again, see above for specifics.

See above why I feel those 2 links are insufficient as an explanation.

--
Joost

[-- Attachment #2: Type: text/html, Size: 36371 bytes --]