[gentoo-dev] eudev project announcement

[gentoo-dev] eudev project announcement

[Richard Yao]

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

Dear Everyone,

	I am pleased to announce the Gentoo eudev project. Many of you already
know about the eudev project from early publicity that we had before
things were ready. Despite that, I hope to take advantage of the
official announcement to explain what we are doing, why we are doing it
and what it means for you. I have broken the announcement into
subsections, each with a title for ease of reading.

Why fork udev?

	Earlier this year, udev upstream was absorbed into systemd. udev often
breaks compatibility with older systems by depending upon recent Linux
kernel releases, even when such dependencies are avoidable. This became
worse after udev became part of systemd, which has jeopardized our
ability to support existing installations. The systemd developers are
uninterested in providing full support in udev to systemd alternatives.
These are problems for us and we have decided to fork udev to address them.

You are a Gentoo project. What does this mean?

	Gentoo as an organization is quite similar to github, although it is
exclusive to Gentoo developers. Our rules permit all Gentoo developers
have the ability to start a project and such projects are entitled to be
hosted on Gentoo infrastructure. This by no means constitutes official
endorsement by Gentoo's governing body and we have no authority to
dictate the future direction of Gentoo. We do have the ability to
provide an alternative to Gentoo users, which we fully intend to do.
	eudev will be by no means exclusive to Gentoo. We will handle bug
reports from users of other distribution in the same way that we handle
bug reports involving Gentoo. This will be much like other Gentoo-hosted
projects such as portage and OpenRC.

What is your project's license?

	The systemd developers were in the middle of a transition to the LGPL
from the GPL when we forked. We inherited the code in the middle of that
transition and we see no reason to pursue a different course. Therefore,
all future changes that we make to eudev will be available under the LGPL.

What are your project's goals?

	Our primary goal is to address the problems with systemd-udev that
caused us to fork it in the first place. In particular, we want better
compatibility with existing software such as OpenRC and Upstart, older
kernels, various toolchains and anything else required by users and
various distributions. We also want to minimize regressions and work
with developers of other distributions (and components used by them) to
address issues.

How will you minimize regressions?

	We intend to maintain HEAD in a releaseable state. All minor changes
require review from one eudev developer and all major changes require
review from two eudev developers. This does not include the author. In
addition, we intend to require commits to make logically independent
changes with descriptive commit messages to make regression hunting
easier when regressions do happen.
	These rules were not enforced at the beginning, but we are
transitioning toward enforcement. They will enter full effect once we
tag our first release candidate.

How do you intend to work with other distributions?

	We have our repository on github, which is known for easy
collaboration. If a distribution developer identifies a problem with
eudev, they can file an issue and we will do our best to resolve their
problem. If they wish to work with us to resolve it, we can talk in IRC
and they can also file pull requests. Provided that the changes are not
entirely unreasonable (e.g. pushing an init system into udev), we are
willing to work with authors of pull requests to get them into a
mergeable state. The only hard rule is that changes cannot break the
ability of existing systems to upgrade.
	We also plan to make an official mailing list, which will be hosted on
Gentoo infrastructure.

Will you make the boot process faster?

	We have ideas on how to make udevd faster. However, people usually only
notice the time that udevd takes when there is a bug and we are more
interested in fixing those bugs than we are in shaving milliseconds off
boot time. There are plenty of areas that could use attention by people
that are interested in a faster boot process before udev becomes one of
them. We consider things such as a reliable boot process to be more
important than speed and we are willing to subject users to the
additional few hundred milliseconds that failing to tweak things for
speed incurs.
	We are already dealing with regressions that the systemd developers
introduced in their attempt to make things faster and we consider fixing
them to be a priority. However, we would be happy to collaborate with
people willing to work on boot speed improvements to get them into a
mergeable state. We encourage people interested in speed improvements to
talk to us about how they could be done in a reasonable manner. It would
be premature to do it at this instant, but it would definitely be
something that could be done after we have tagged a few stable releases.

What did systemd break when trying to make things faster?

	A good example involves module loading. Previously, each module load
would incur a roughly 10 to 20 ms disk access latency and a 0.01 ms fork
overhead. This was partially masked by udev's ability to execute rules
asynchronously through fork(), which meant that multiple modules could
be read in parallel.
	The introduction of kmod eliminated the 0.01 ms fork() overhead, and
consequently required each module to be loaded sequentially. This
imposes an overhead of 10 to 20 milliseconds times the number of
modules, which is asymptotically worse than what it replaced. A feature
of kmod intended to address that placed all modules into a single file,
which would actually make things faster. However, none of our users use
it and all of our users would suffer from it.
	In addition, the manner in which kmod was integrated has implications
beyond speed regressions. The use of kmod by udev permits a buggy kernel
module (possibly interacting with bad hardware) to hang in module_init.
This causes udevd to hang, which prevents further rule processing. This
is a bad situation, but we feel that it is important to handle bad
situations in a graceful manner. Previously, the system would have a
chance of booting in this situation. The manner in which kmod was
introduced makes this situation far more likely to cripple systems.
	If you want to understand the worst case scenario when dealing with
this regression, disable udev and reboot your system. You should have a
virtual terminal with no networking and no X. Should this happen with
systemd-udevd, then you would also have a hung systemd-udevd process
that you cannot kill. Attempts restart systemd-udevd should result in
more hung processes.

Where is development now?

	We have rewritten the build system and restored support for older
kernels and verified compatibility as far back as Linux 2.6.31. We have
tagged 1_beta1 and eudev is in the portage tree. A few lingering
dependency issues exist, but we should have them ironed out shortly.
	Work is on-going to introduce uclibc support, to reintroduce
70-persistent-net.rules and to reintroduce support for a separate /usr
support without an initramfs. Strictly speaking, we do not recommend
having a separate /usr mount, but we intend to support such
configurations in eudev indefinitely.
	We are also looking into fixing various regressions that the systemd
developers introduced, which include the kmod regressions.

What are your plans for future development?

	We intend to demonstrate to the current Gentoo udev maintainers that
maintaining systemd-udevd outside of the systemd package is unnecessary
when we have eudev. If they wish to continue maintaining systemd-udevd
as they are, then that is fine unless the Gentoo Council decides otherwise.
	After eudev has reached stable status in Gentoo, we intend to start
reaching out to other distributions to collaborate on further
development. Ideally, eudev will be something that all distributions can
use as a drop-in replacement for systemd-udevd.

Yours truly,
Richard Yao

P.S. I have BCCed a few people that might be interested in reading the
project announcement. Unfortunately, the gentoo-dev list requires
registration to avoid spammers, so you will need to register to reply to
the list. Documentation on how to register on the list is available at
the following address:

http://www.gentoo.org/main/en/lists.xml


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] eudev project announcement

[Richard Yao]

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

On 12/14/2012 10:52 PM, Richard Yao wrote:
> Dear Everyone,
> 
> 	I am pleased to announce the Gentoo eudev project. Many of you already
> know about the eudev project from early publicity that we had before
> things were ready. Despite that, I hope to take advantage of the
> official announcement to explain what we are doing, why we are doing it
> and what it means for you. I have broken the announcement into
> subsections, each with a title for ease of reading.

Thunderbird's autocompletion appears to have caused me to send this to
gentoo-dev-announce+subscribe by mistake. I have sent out a second email
to correct that.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] eudev project announcement

[Peter Stuge]

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

Richard Yao wrote:
> Where is development now?
> 
> 	We have rewritten the build system and restored support for older
> kernels and verified compatibility as far back as Linux 2.6.31. We have
> tagged 1_beta1 and eudev is in the portage tree. A few lingering
> dependency issues exist, but we should have them ironed out shortly.

Not yet something I care about. (That's fine.)

I hope that eudev wants to do the respectable thing for any fork, ie.
work hard to minimize the amount of wasted effort in both projects by
sharing much code and bugfixes.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

[gentoo-dev] Re: eudev project announcement

[Nikos Chantziaras]

On 15/12/12 06:16, Peter Stuge wrote:
> Richard Yao wrote:
>> Where is development now?
>>
>> 	We have rewritten the build system and restored support for older
>> kernels and verified compatibility as far back as Linux 2.6.31. We have
>> tagged 1_beta1 and eudev is in the portage tree. A few lingering
>> dependency issues exist, but we should have them ironed out shortly.
>
> Not yet something I care about. (That's fine.)
>
> I hope that eudev wants to do the respectable thing for any fork, ie.
> work hard to minimize the amount of wasted effort in both projects by
> sharing much code and bugfixes.

I, on the other hand, hope that this isn't an indication of Gentoo not 
being interested in systemd.  I'm eagerly awaiting the moment where I 
can "emerge systemd" and just have it working.

Re: [gentoo-dev] eudev project announcement

[Walter Dnes]

On Sat, Dec 15, 2012 at 05:16:48AM +0100, Peter Stuge wrote

> I hope that eudev wants to do the respectable thing for any fork, ie.
> work hard to minimize the amount of wasted effort in both projects by
> sharing much code and bugfixes.

  That would be nice if systemd/udev upstream was agreeable.  On the
other hand, if the systemd/udev maintainers had accepted bug reports
("WONTFIX" is not acceptance) and had accepted proposed patches, there
wouldn't have been a need for the eudev fork in the first place.
Lennart Poettering has admitted systemd's outright hostility to to
standalone udev...
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

> Well, we intent to continue to make it possible to run udevd outside
> of systemd. But that's about it. We will ***NOT POLISH THAT, OR ADD
> NEW FEATURES*** to that or anything.
> 
> OTOH we do polish behaviour of udev when used *within* systemd
> however, and that's our primary focus.
> 
> And what we will ***CERTAINLY NOT DO IS COMPROMISE THE UNIFORM
> INTEGRATION INTO SYSTEMD FOR SOME COSMETIC IMPROVEMENTS FOR
> NON-SYSTEMD SYSTEMS***.
> 
> (Yes, udev on non-systemd systems is in our eyes a dead end, in case
> you haven't noticed it yet. I am looking forward to the day when we
> can drop that support entirely.)

  They've essentially announced ahead of time that most bugs from
non-systemd users would be closed with WONTFIX.  Actually, for political
reasons, I hope that eudev does submit a bunch bugs+patches, and gets
them rejected.  Then whenever anyone complains about not sharing code,
show them a bunch of WONTFIX emails from systemd/udev maintainers.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[gentoo-dev] Re: eudev project announcement

[Duncan]

Walter Dnes posted on Sat, 15 Dec 2012 01:33:04 -0500 as excerpted:

> [Udev-systemd has] essentially announced ahead of time that most bugs
> from non-systemd users would be closed with WONTFIX.

Agreed, to this point.

> Actually, for political reasons, I hope that eudev does submit a bunch
> bugs+patches, and gets them rejected.  Then whenever anyone complains
> about not sharing code, show them a bunch of WONTFIX emails from
> systemd/udev maintainers.

This attitude is and the described events would be... unfortunate.

For the reasons you list, I don't believe people should be /surprised/ if 
many such bugs+patches are rejected after submission, but that wouldn't 
make it any less unfortunate, and IMO, hoping they DO get rejected is the 
wrong attitude to have.

The best possible outcome, IMO, would be that the eudev (and any other 
udev replacement projects) eventually work themselves out of a job.  
Ideally, the very existence of these projects will trigger a rethink on 
the part of the udev folks, causing the reasons for the fork to disappear 
over time.  Ideally, with effort and compromise on NIH and similar 
attitudes on /both/ sides, differences can be put aside and udev (whether 
it remains developed under the systemd umbrella or not) can once again be 
the unifying influence its authors claim to intend.

To some extent the hubbub has already appeared to trigger incremental 
walkbacks and/or the exploration of third ways.  The kernel's recent 
addition of its own module loading code, endorsed by the udev folks, is 
one such third way development.  Perhaps I'm reading my own viewpoint 
into things, but it seems from here anyway, that the systemd-udev side 
rhetoric on initr*-less support for a separate /usr is... less 
strident... than it was.  And kmod was initially required by new udev, 
but is now optional.  I'd call all of these good developments... that may 
well have never occurred had pushback including but not limited to the 
eudev project hadn't occurred.

Ideally, then, the need for eudev as an actually installed systemd-udev 
alternative will disappear even as eudev is being born.  However, that's 
no argument yet for termination of the project and in fact is arguably 
the reverse, given systemd and now udev's history of ignoring feedback 
from those it's riding roughshod over, as long as people continue to LET 
it ride roughshod over them.  The existence of the eudev project, 
therefore, may continue to be necessary, if only to provide a practical 
udev alternative such that udev itself moderates to the point that the 
alternative need not be actually used on a system.

But at least there's an alternative now, so that regardless of whether 
systemd-udev moderates or not, people aren't left without recourse.  
Hopefully that moderation occurs and the alternatives can ultimately be 
merged back in, but there's recourse now, so people are no longer 
actually dependent on udev-systemd's moderation.

Which way that takes both udev-systemd and eudev remains to be seen, but 
I'd /still/ consider it /unfortunate/ if those bugs+patches do appear and 
get WONTFIXed, thus, certainly I hope they appear, but just as certainly, 
one can HOPE they get resolved/merged, *NOT* resolved/WONTFIXed.

Time will tell.

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

Re: [gentoo-dev] eudev project announcement

[Roy Bamford]

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

On 2012.12.15 03:52, Richard Yao wrote:
> Dear Everyone,
> 
> 	I am pleased to announce the Gentoo eudev project. 
[snip]
> 
> Yours truly,
> Richard Yao
> 
[snip]

I welcome the choice that this new project brings, that's what Gentoo 
is about - choice.

I wish eudev both good luck and success.  Success comes in many forms, 
so I won't try to predict exactly what that means. Suffice to say, we 
will all recognise it when we see it.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Rich Freeman]

On Sat, Dec 15, 2012 at 12:28 AM, Nikos Chantziaras <realnc@gmail.com> wrote:
>
> I, on the other hand, hope that this isn't an indication of Gentoo not being
> interested in systemd.  I'm eagerly awaiting the moment where I can "emerge
> systemd" and just have it working.

Gentoo is a community - of which you are a part.  There are many
commonalities that tend to bring us together, like our desire for the
flexibility and choice that a source-base distro provides.  The very
forces that drove some to create eudev virtually guarantee that others
will provide a mature systemd implementation (well, insofar as there
is an upstream to provide one).

I'm running systemd on a VM right now - getting it running really
isn't that difficult - worst case you might have a few packages that
didn't install unit files, but for that matter not all packages
install init.d scripts either.  Patches to provide either should
generally be accepted by maintainers if they are in good order.

Rich

Re: [gentoo-dev] eudev project announcement

[Dale]

Roy Bamford wrote:
> On 2012.12.15 03:52, Richard Yao wrote:
>> Dear Everyone,
>>
>> 	I am pleased to announce the Gentoo eudev project. 
> [snip]
>> Yours truly,
>> Richard Yao
>>
> [snip]
>
> I welcome the choice that this new project brings, that's what Gentoo 
> is about - choice.
>
> I wish eudev both good luck and success.  Success comes in many forms, 
> so I won't try to predict exactly what that means. Suffice to say, we 
> will all recognise it when we see it.
>

+1 and I'm looking forward to using it too. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

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

[Rich Freeman]

On Fri, Dec 14, 2012 at 10:52 PM, Richard Yao <ryao@gentoo.org> wrote:
>         The systemd developers were in the middle of a transition to the LGPL
> from the GPL when we forked. We inherited the code in the middle of that
> transition and we see no reason to pursue a different course. Therefore,
> all future changes that we make to eudev will be available under the LGPL.

Not sure what the driver is to use LGPL, but in general the Gentoo
social contract requires that all contributions be made under GPLv2+
or the CC BY-SAv2+.  I'm sure exceptions can be made if they make
sense and are aligned with Gentoo's mission (likely something that
would fall on the Foundation to approve).  If eudev were a non-Gentoo
project then Gentoo could depend on it as long as it used any
OSI-approved license.

Why not just use GPLv2+?  The LGPL is compatible, so this would not
prevent us from merging udev changes.

Not suggesting that we shouldn't use the LGPL if there is a good
reason to do so that is aligned with Gentoo's mission.  I would just
like to understand the reason for it.

Rich

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

[Duncan]

Rich Freeman posted on Sat, 15 Dec 2012 07:48:29 -0500 as excerpted:

> On Fri, Dec 14, 2012 at 10:52 PM, Richard Yao <ryao@gentoo.org> wrote:
>>         The systemd developers were in the middle of a transition to
>>         the LGPL
>> from the GPL when we forked. We inherited the code in the middle of
>> that transition and we see no reason to pursue a different course.
>> Therefore, all future changes that we make to eudev will be available
>> under the LGPL.
> 
> Not sure what the driver is to use LGPL, but in general the Gentoo
> social contract requires that all contributions be made under GPLv2+ or
> the CC BY-SAv2+.  I'm sure exceptions can be made if they make sense and
> are aligned with Gentoo's mission (likely something that would fall on
> the Foundation to approve).  If eudev were a non-Gentoo project then
> Gentoo could depend on it as long as it used any OSI-approved license.
> 
> Why not just use GPLv2+?  The LGPL is compatible, so this would not
> prevent us from merging udev changes.
> 
> Not suggesting that we shouldn't use the LGPL if there is a good reason
> to do so that is aligned with Gentoo's mission.  I would just like to
> understand the reason for it.

The biggest reason surely must be two-way license compatibility with 
udev, allowing patch-flow both ways.  As I said in an earlier post, at 
least from my perspective, the ideal outcome would be that the very 
presence of eudev creates conditions where the reasons why it was forked 
no longer exist, and the two projects can ultimately remerge.  Surely, as 
a fork the PR problems are bad enough, and we don't want to be the ones 
deliberately throwing legal/license road blocks into the way of two-way 
patch-flow, making the situation worse.  If the conditions that triggered 
eudev forking don't improve, let it be due to decisions from the OTHER 
side, not due to decisions here.

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

Re: [gentoo-dev] eudev project announcement

[Anthony G. Basile]

On 12/15/2012 01:33 AM, Walter Dnes wrote:
> On Sat, Dec 15, 2012 at 05:16:48AM +0100, Peter Stuge wrote
>
>> I hope that eudev wants to do the respectable thing for any fork, ie.
>> work hard to minimize the amount of wasted effort in both projects by
>> sharing much code and bugfixes.
>    That would be nice if systemd/udev upstream was agreeable.  On the
> other hand, if the systemd/udev maintainers had accepted bug reports
> ("WONTFIX" is not acceptance) and had accepted proposed patches, there
> wouldn't have been a need for the eudev fork in the first place.
> Lennart Poettering has admitted systemd's outright hostility to to
> standalone udev...
> http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
>
>> Well, we intent to continue to make it possible to run udevd outside
>> of systemd. But that's about it. We will ***NOT POLISH THAT, OR ADD
>> NEW FEATURES*** to that or anything.
>>
>> OTOH we do polish behaviour of udev when used *within* systemd
>> however, and that's our primary focus.
>>
>> And what we will ***CERTAINLY NOT DO IS COMPROMISE THE UNIFORM
>> INTEGRATION INTO SYSTEMD FOR SOME COSMETIC IMPROVEMENTS FOR
>> NON-SYSTEMD SYSTEMS***.
>>
>> (Yes, udev on non-systemd systems is in our eyes a dead end, in case
>> you haven't noticed it yet. I am looking forward to the day when we
>> can drop that support entirely.)
>    They've essentially announced ahead of time that most bugs from
> non-systemd users would be closed with WONTFIX.  Actually, for political
> reasons, I hope that eudev does submit a bunch bugs+patches, and gets
> them rejected.  Then whenever anyone complains about not sharing code,
> show them a bunch of WONTFIX emails from systemd/udev maintainers.
>
I'm not interested in forming that kind of relationship with the systemd 
people.  I actually have some issues I'm thinking of passing their way.  
But I will limit myself to only those thing which I believe will make 
systemd/udev better.  I hope they pass the same sort of bugreports/fixes 
our way for a standalone udev consistent with our project goals.

I respect Poettering's position in that email whether or he respect 
mine.  They have their priorities and we have our.  I say that without 
any hard feelings.  Its the way things should work in open source.  The 
only downside to forking is a division of effort.  It pulls me away from 
my other projects.  But that's my freedom.  And now I'd better stop 
before I start sounding like Stallman.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

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

[Luca Barbato]

On 12/15/2012 01:48 PM, Rich Freeman wrote:
> On Fri, Dec 14, 2012 at 10:52 PM, Richard Yao <ryao@gentoo.org> wrote:
>>         The systemd developers were in the middle of a transition to the LGPL
>> from the GPL when we forked. We inherited the code in the middle of that
>> transition and we see no reason to pursue a different course. Therefore,
>> all future changes that we make to eudev will be available under the LGPL.
> 
> Not sure what the driver is to use LGPL, but in general the Gentoo
> social contract requires that all contributions be made under GPLv2+
> or the CC BY-SAv2+. 

"
We will release our contributions to Gentoo as free software, metadata
or documentation, under the GNU General Public License version 2 (or
later, at our discretion) or the Creative Commons - Attribution / Share
Alike version 2 (or later, at our discretion). Any external
contributions to Gentoo (in the form of freely-distributable sources,
binaries, metadata or documentation) may be incorporated into Gentoo
provided that we are legally entitled to do so. However, Gentoo will
never depend upon a piece of software or metadata unless it conforms to
the GNU General Public License, the GNU Lesser General Public License,
the Creative Commons - Attribution/Share Alike or some other license
approved by the Open Source Initiative (OSI).
"

eudev is a Gentoo project is not Gentoo. Same could be said for OpenRC.

> Why not just use GPLv2+?  The LGPL is compatible, so this would not
> prevent us from merging udev changes.

udev and eudev provide:

- a daemon
- a set of core rules
- a library to let applications interact with udev (libudev)
- a generic language binding using glib-introspection (libgudev)

makes perfectly sense to have libraries using LGPL (or even more
permissive licenses).

I guess you misunderstood what is Gentoo and what is a Gentoo Project.

lu

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

[Rich Freeman]

On Sat, Dec 15, 2012 at 10:43 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
>
>
> eudev is a Gentoo project is not Gentoo. Same could be said for OpenRC.
>

OpenRC isn't a Gentoo project, at least, it wasn't in the past.

The social contract defines Gentoo as a collection of free knowledge,
which includes "free software contributed by various developers to the
Gentoo Project."  The social contract is meaningless if it doesn't
apply to Gentoo projects.  Gentoo projects cover all the arch teams,
portage, and all of our documentation.

Projects are just how we organize the administration of Gentoo. They
aren't something distinct from Gentoo.  When you work on a Gentoo
project, you work on Gentoo.

> I guess you misunderstood what is Gentoo and what is a Gentoo Project.
>

Enlighten us, what is Gentoo, if nothing in any Gentoo project is Gentoo?

What exactly do you think that section of the Social Contract actually
covers?  Or is it a pretty document we stick on our website but ignore
when it is somehow inconvenient?

As I said, I'm fine with making exceptions if it makes sense and
furthers the overall mission of Gentoo.  However, we shouldn't just
ignore the social contract without any kind of consideration at all.
If the community doesn't like the social contract we could of course
consider amending it as well.

Gentoo isn't GitHub.  When people donate money to Gentoo they're not
donating so that a club of elite coders can use the infrastructure to
host just anything that suits their fancy.  The reason that we let any
Gentoo developer just start a project is because it helps promote
innovation and cuts through bureaucracy.  That doesn't mean that
Gentoo holds no interest in the work that is done under its name.

I think that Duncan pointed out a great reason to use LGPL, and using
a license that lets us better collaborate with the overall FOSS
community is something I think is well-aligned with Gentoo's mission
(We Will Give Back to the Free Software Community).  However, if we
use LGPL it should because of something like this, and not simply be
because those working on the project picked it.  If for whatever
reason the fork diverges to a point where we aren't giving back in the
form of patches to upstream then I'd argue that it would make sense to
move back to the GPL (something trivially done with or without
copyright assignment due to the nature of the LGPL).

Rich

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

[Walter Dnes]

On Sat, Dec 15, 2012 at 07:21:21AM +0000, Duncan wrote
> Walter Dnes posted on Sat, 15 Dec 2012 01:33:04 -0500 as excerpted:
> 
> > [Udev-systemd has] essentially announced ahead of time that most bugs
> > from non-systemd users would be closed with WONTFIX.
> 
> Agreed, to this point.
> 
> > Actually, for political reasons, I hope that eudev does submit a bunch
> > bugs+patches, and gets them rejected.  Then whenever anyone complains
> > about not sharing code, show them a bunch of WONTFIX emails from
> > systemd/udev maintainers.
> 
> This attitude is and the described events would be... unfortunate.
> 
> For the reasons you list, I don't believe people should be /surprised/ if 
> many such bugs+patches are rejected after submission, but that wouldn't 
> make it any less unfortunate, and IMO, hoping they DO get rejected is the 
> wrong attitude to have.

  I should've been clearer in my email, rather than a train-of-thought
approach...

  1) For appearance's sake and to make our position better in outsiders'
view, I *HOPE* that eudev developers are co-operative in regards to
sharing patches with systemd/udev.

  2) Given past history, I *EXPECT* at least some bugs to be "resolved"
by the systemd/udev developers as WONTFIX.  It was their attitude that
led to eudev in the first place.

  Here's a brief overview of why I think that eudev (or equivalant) is
necessary...

  * Lennart Poettering wrote systemd

  * systemd will not run on machines with a separate /usr, and no
    initramfs.

  * Some people say that's because systemd is broken.  Lennart says that
    machines systemd won't run on are broken.

  * That's getting into "holy war" territory.  If it had remained
    strictly a Redhat-ism, we wouldn't be arguing the issue today.

  * The udevd tarball got merged into the systemd tarball, in order to
    "share common code".  That's when the fruit of the cow-pasture hit
    the fan.

  * Inheriting code from from systemd meant inheriting any restrictions
    that code had... e.g. not supporting separate /usr without initramfs

  That's just now.  What other systemd-related restrictions/dependancies
will be eventually rammed down the throats of non-users of systemd?
eudev is a "declaration of independance" for non-systemd users.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Michał Górny]

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

On Sat, 15 Dec 2012 12:53:41 -0500
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Sat, Dec 15, 2012 at 07:21:21AM +0000, Duncan wrote
> > Walter Dnes posted on Sat, 15 Dec 2012 01:33:04 -0500 as excerpted:
> > 
> > > [Udev-systemd has] essentially announced ahead of time that most bugs
> > > from non-systemd users would be closed with WONTFIX.
> > 
> > Agreed, to this point.
> > 
> > > Actually, for political reasons, I hope that eudev does submit a bunch
> > > bugs+patches, and gets them rejected.  Then whenever anyone complains
> > > about not sharing code, show them a bunch of WONTFIX emails from
> > > systemd/udev maintainers.
> > 
> > This attitude is and the described events would be... unfortunate.
> > 
> > For the reasons you list, I don't believe people should be /surprised/ if 
> > many such bugs+patches are rejected after submission, but that wouldn't 
> > make it any less unfortunate, and IMO, hoping they DO get rejected is the 
> > wrong attitude to have.
> 
>   I should've been clearer in my email, rather than a train-of-thought
> approach...
> 
>   1) For appearance's sake and to make our position better in outsiders'
> view, I *HOPE* that eudev developers are co-operative in regards to
> sharing patches with systemd/udev.
> 
>   2) Given past history, I *EXPECT* at least some bugs to be "resolved"
> by the systemd/udev developers as WONTFIX.  It was their attitude that
> led to eudev in the first place.
> 
>   Here's a brief overview of why I think that eudev (or equivalant) is
> necessary...
> 
>   * Lennart Poettering wrote systemd
> 
>   * systemd will not run on machines with a separate /usr, and no
>     initramfs.

Waaait, what? Did something change lately or are you just repeating
the same bullshit for months?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Walter Dnes]

On Sat, Dec 15, 2012 at 07:07:09PM +0100, Micha?? G??rny wrote
> 
> Waaait, what? Did something change lately or are you just repeating
> the same bullshit for months?

  Older systemd boots OK with a separate /usr and eudev.  But somehow,
somewhere along the line, as part of the merge, the udev portion of the
systemd tarball requires initramfs.  See news item...
http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=36326;list=gentoo
It was actually finally released 2012-03-16.  If you disagree with that
news item, complain directly to its author.  If you can boot a udev-181
or higher system with a separate /usr, and no intrd/initramfs, I'm sure
a lot of people would be very interested in knowing how.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Michał Górny]

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

On Sat, 15 Dec 2012 13:58:43 -0500
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Sat, Dec 15, 2012 at 07:07:09PM +0100, Micha?? G??rny wrote
> > 
> > Waaait, what? Did something change lately or are you just repeating
> > the same bullshit for months?
> 
>   Older systemd boots OK with a separate /usr and eudev.  But somehow,
> somewhere along the line, as part of the merge, the udev portion of the
> systemd tarball requires initramfs.  See news item...
> http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=36326;list=gentoo
> It was actually finally released 2012-03-16.  If you disagree with that
> news item, complain directly to its author.  If you can boot a udev-181
> or higher system with a separate /usr, and no intrd/initramfs, I'm sure
> a lot of people would be very interested in knowing how.

This was a Gentoo decision, not an upstream one.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Richard Yao]

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

On 12/15/2012 02:33 PM, Michał Górny wrote:
> On Sat, 15 Dec 2012 13:58:43 -0500
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> 
>> On Sat, Dec 15, 2012 at 07:07:09PM +0100, Micha?? G??rny wrote
>>>
>>> Waaait, what? Did something change lately or are you just repeating
>>> the same bullshit for months?
>>
>>   Older systemd boots OK with a separate /usr and eudev.  But somehow,
>> somewhere along the line, as part of the merge, the udev portion of the
>> systemd tarball requires initramfs.  See news item...
>> http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=36326;list=gentoo
>> It was actually finally released 2012-03-16.  If you disagree with that
>> news item, complain directly to its author.  If you can boot a udev-181
>> or higher system with a separate /usr, and no intrd/initramfs, I'm sure
>> a lot of people would be very interested in knowing how.
> 
> This was a Gentoo decision, not an upstream one.
> 

If I recall, WilliamH stated at the time that he believed that upstream
would make avoiding it increasingly difficult. My impression was that he
felt coerced into making that change.

I suspect that the following statement from Lennart Poettering is the
reason why WilliamH appeared to feel coerced:

>
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
>
>> Well, we intent to continue to make it possible to run udevd outside
>> of systemd. But that's about it. We will ***NOT POLISH THAT, OR ADD
>> NEW FEATURES*** to that or anything.
>>
>> OTOH we do polish behaviour of udev when used *within* systemd
>> however, and that's our primary focus.
>>
>> And what we will ***CERTAINLY NOT DO IS COMPROMISE THE UNIFORM
>> INTEGRATION INTO SYSTEMD FOR SOME COSMETIC IMPROVEMENTS FOR
>> NON-SYSTEMD SYSTEMS***.
>>
>> (Yes, udev on non-systemd systems is in our eyes a dead end, in case
>> you haven't noticed it yet. I am looking forward to the day when we
>> can drop that support entirely.)

When he says "udev on non-systemd systems", he clearly means anything
outside of his narrow definition of what he considers to be a supported
configuration. That is his decision and I can respect that, but to hold
upstream as being separate from the decision by the Gentoo udev
maintainers is inaccurate.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Luca Barbato]

On 12/15/2012 05:20 PM, Rich Freeman wrote:
> On Sat, Dec 15, 2012 at 10:43 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
>>
>>
>> eudev is a Gentoo project is not Gentoo. Same could be said for OpenRC.
>>
> 
> OpenRC isn't a Gentoo project, at least, it wasn't in the past.
> 
> The social contract defines Gentoo as a collection of free knowledge,
> which includes "free software contributed by various developers to the
> Gentoo Project."  The social contract is meaningless if it doesn't
> apply to Gentoo projects.  Gentoo projects cover all the arch teams,
> portage, and all of our documentation.

That part of the social contract section is resembling really closely
Debian and shares the same clashing issue when Gentoo has to mix with
non-gpl realities such as FreeBSD. We are not going to relicense to GPL
all the software we touch, it would be at least rude.

> Projects are just how we organize the administration of Gentoo. They
> aren't something distinct from Gentoo.  When you work on a Gentoo
> project, you work on Gentoo.

Again, looks like there is a huge misunderstanding on what a project is,
the term is much often overloaded since you have Gentoo, the community
and the distribution and projects fostered by Gentoo.

>> I guess you misunderstood what is Gentoo and what is a Gentoo Project.
>>
> 
> Enlighten us, what is Gentoo, if nothing in any Gentoo project is Gentoo?

See above =)

> What exactly do you think that section of the Social Contract actually
> covers?  Or is it a pretty document we stick on our website but ignore
> when it is somehow inconvenient?

The social contract is meant to assure that we will preserve and
maintain the freedoms we got as foundation the best we could. That
section is clumsy in stating it as is in Debian, agreed.

> As I said, I'm fine with making exceptions if it makes sense and
> furthers the overall mission of Gentoo.

There is no exception to be made.

> However, we shouldn't just ignore the social contract without any kind
> of consideration at all.

Again, the document doesn't really relate to any "Gentoo project" as
expressed as anything different from the distribution as whole.

> If the community doesn't like the social contract we could of course
> consider amending it as well.

Clarifying to avoid such misunderstandings it seems necessary.

> Gentoo isn't GitHub.  When people donate money to Gentoo they're not
> donating so that a club of elite coders can use the infrastructure to
> host just anything that suits their fancy.  The reason that we let any
> Gentoo developer just start a project is because it helps promote
> innovation and cuts through bureaucracy.  That doesn't mean that
> Gentoo holds no interest in the work that is done under its name.

Again, we have a number of projects under permissive licenses since we
DO want work with the BSD community or we rely on software originated by
them, relicensing any software to GPL would be rude and quite pointless.

I'm afraid you are ignoring the fact core libraries should not be GPL to
not hinder adoption. (check which software uses libudev or libgudev and
see how much of it won't work anymore had you relicensed those libraries
to GPL)

> If for whatever reason the fork diverges to a point where we aren't
> giving back in the form of patches to upstream then I'd argue that it
> would make sense to move back to the GPL (something trivially done with
> or without copyright assignment due to the nature of the LGPL).

I'd be happy to consider this once we reach this stage and you are among
the main contributors.

Currently I guess people would be happy to have their udev working as
should.

lu

Re: [gentoo-dev] eudev project announcement

[Richard Yao]

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

On 12/14/2012 11:16 PM, Peter Stuge wrote:
> Richard Yao wrote:
>> Where is development now?
>>
>> 	We have rewritten the build system and restored support for older
>> kernels and verified compatibility as far back as Linux 2.6.31. We have
>> tagged 1_beta1 and eudev is in the portage tree. A few lingering
>> dependency issues exist, but we should have them ironed out shortly.
> 
> Not yet something I care about. (That's fine.)
> 
> I hope that eudev wants to do the respectable thing for any fork, ie.
> work hard to minimize the amount of wasted effort in both projects by
> sharing much code and bugfixes.
> 
> 
> //Peter

The systemd developers have made it clear that they are not interested
in supporting systems that we wish to support. That is why we forked. We
intend to keep under a compatible license so that they can cherry-pick
patches that they deem to fit their narrow criteria for being
appropriate. However, it would be a waste of valuable development time
for us to cherry-pick patches for them on the chance that they might
decide to consider entertaining the idea of merging them.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Richard Yao]

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

On 12/15/2012 11:20 AM, Rich Freeman wrote:
> Gentoo isn't GitHub.  When people donate money to Gentoo they're not
> donating so that a club of elite coders can use the infrastructure to
> host just anything that suits their fancy.  The reason that we let any
> Gentoo developer just start a project is because it helps promote
> innovation and cuts through bureaucracy.  That doesn't mean that
> Gentoo holds no interest in the work that is done under its name.

I made the github comparison as a simplification to preempt further
notions of the idea that being a Gentoo project reflects a collective
agreement that we are abandoning systemd-udevd in our distribution.

> I think that Duncan pointed out a great reason to use LGPL, and using
> a license that lets us better collaborate with the overall FOSS
> community is something I think is well-aligned with Gentoo's mission
> (We Will Give Back to the Free Software Community).  However, if we
> use LGPL it should because of something like this, and not simply be
> because those working on the project picked it.  If for whatever
> reason the fork diverges to a point where we aren't giving back in the
> form of patches to upstream then I'd argue that it would make sense to
> move back to the GPL (something trivially done with or without
> copyright assignment due to the nature of the LGPL).

The systemd developers have made it clear that they are not interested
in our changes. That is why we forked in the first place. Our plan is to
keep the door open for them to cherry-pick patches should they decide to
start supporting some of the system configurations that we support. I
consider this to be the reason why OSS developers give away source code
in the first place.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] eudev project announcement

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please, you have your own mailing list. Use it.

- -ZC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQzOm7AAoJEKXdFCfdEflKZ9YP/iwUIKYhpE6b7+3Jp0m4s76/
i5Qck3CP6CeKAYPnh3M1hA3TlT/U6CLedS+byCOJF0albITq0Rs40t5O6rx9eBtl
Cz3RbnSJiJChEyHL+2kcmBSLQT2t0kzwiK5zNcW3Xv5HQN9JmO8QkIdnnH28SV5h
iYOwe1KrAoY5ZKu/yRqvqA7Z7TmnZ/nafu+iVMN3MGAkO7xd49/ustXrG6qRllLL
lfWDSQRz611by6cafKtmq+NlZXfUy5DCDkToKInQGUtSolenZ3QqsmC0Q5qKBwQa
I9iYUjMubVCtkT4K3GxIs4294EtW8IebdApqTC+lgqkvQnbHmmysvwtNoh0V1I8h
z9yad8GWZPIT6nGHnPGJMJPqE8RGZtLBdGlQLVhRKM6WdVWQrPsvql+415l42487
RLOwAyiwXk4Iz20sotHjsGbv16CCEIAsiBhzV7r8mIPnNuFff7I9OvfzRAMD5fBQ
Jy5ZzGbuZlRURzNwXXnNGPaR19GbWxIoLg3sS+NNzFQ5OE2zxwgsYptoH5TMDJlN
g8T4mwGQ531Glx0cUveGUjIh4xe9I6GeTjNGpRryCSEht2T/eRrm765VQPTMoZrF
DYoy2BJXjl3r0sExQvkNxjMT7qp0amV9eQ3n9FirYFNztzCaFSJW3QfsNoppi0ge
dDYzc/Hu9GKyVyBt+LHe
=vdSS
-----END PGP SIGNATURE-----

Re: [gentoo-dev] eudev project announcement

[Richard Yao]

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

On 12/15/2012 04:20 PM, Rick "Zero_Chaos" Farina wrote:
> Please, you have your own mailing list. Use it.
> 
> -ZC
> 

I am under the impression that project announcements must be sent to
gentoo-dev-announce@ and set Reply-To: gentoo-dev@.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

[gentoo-dev] Re: eudev project announcement

[Duncan]

Walter Dnes posted on Sat, 15 Dec 2012 12:53:41 -0500 as excerpted:

> On Sat, Dec 15, 2012 at 07:21:21AM +0000, Duncan wrote
>> Walter Dnes posted on Sat, 15 Dec 2012 01:33:04 -0500 as excerpted:
>> 
>>> Actually, for political reasons, I hope that eudev does submit a
>>> bunch bugs+patches, and gets them rejected.  Then whenever anyone
>>> complains about not sharing code, show them a bunch of WONTFIX emails
>>> from systemd/udev maintainers.
>> 
>> This attitude is and the described events would be... unfortunate.
>> 
>> For the reasons you list, I don't believe people should be /surprised/
>> if many such bugs+patches are rejected after submission, but that
>> wouldn't make it any less unfortunate, and IMO, hoping they DO get
>> rejected is the wrong attitude to have.
> 
> I should've been clearer in my email, rather than a train-of-thought
> approach...
> 
> 1) For appearance's sake and to make our position better in outsiders'
> view, I *HOPE* that eudev developers are co-operative in regards to
> sharing patches with systemd/udev.
> 
> 2) Given past history, I *EXPECT* at least some bugs to be "resolved"
> by the systemd/udev developers as WONTFIX.  It was their attitude that
> led to eudev in the first place.

OK, /that/ I agree with.  Keep the two-way open from our side so that 
it's their decision, not ours.  Given history, I can't see anyone being 
terribly surprised if they reject as WONTFIX, but let it be their 
decision, not ours.

There's as many differences as parallels, but I keep thinking of the 
openoffice/libreoffice split.  The libreoffice folks bent over backward 
to keep the license and code something that Oracle/IBM could still use, 
tho they chose not to.  But that was their decision, not the decision of 
the libreoffice folks.  If the systemd-udev/eudev split endures, we could 
surely do a lot worse than libreoffice and still count it success, and I 
think we'd do well to emulate them in our bending over backward to retain 
legal and code reusability between the projects.  If they choose not to 
take advantage, well, that's on them.  As with lo/ooo, it may be that the 
code diverges over time, but let's not throw up artificial barriers to 
sharing immediately, nor hope that they don't take advantage, even if we 
won't be surprised should they chose not to.

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

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

[Olav Vitters]

On Sat, Dec 15, 2012 at 03:17:05PM -0500, Richard Yao wrote:
> On 12/15/2012 02:33 PM, Michał Górny wrote:
> > On Sat, 15 Dec 2012 13:58:43 -0500
> > "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> >> On Sat, Dec 15, 2012 at 07:07:09PM +0100, Micha?? G??rny wrote
> >>> Waaait, what? Did something change lately or are you just repeating
> >>> the same bullshit for months?
> >>
> >>   Older systemd boots OK with a separate /usr and eudev.  But somehow,
> >> somewhere along the line, as part of the merge, the udev portion of the
> >> systemd tarball requires initramfs.  See news item...
> >> http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=36326;list=gentoo
> >> It was actually finally released 2012-03-16.  If you disagree with that
> >> news item, complain directly to its author.  If you can boot a udev-181
> >> or higher system with a separate /usr, and no intrd/initramfs, I'm sure
> >> a lot of people would be very interested in knowing how.
> > 
> > This was a Gentoo decision, not an upstream one.
> 
> If I recall, WilliamH stated at the time that he believed that upstream
> would make avoiding it increasingly difficult. My impression was that he
> felt coerced into making that change.

So systemd still works with a separate /usr and you're continuing to
spread misinformation. Demonstrating such behaviour while complaining
about the behaviour of upstream is IMO very ironic.
-- 
Regards,
Olav

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

[Luca Barbato]

On 12/17/12 11:40 AM, Olav Vitters wrote:
> So systemd still works with a separate /usr and you're continuing to
> spread misinformation. Demonstrating such behaviour while complaining
> about the behaviour of upstream is IMO very ironic.

No it does not, try by yourself please ^^

(or just issue and ldd over the main binaries)

lu

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

[Richard Yao]

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

On 12/17/2012 05:40 AM, Olav Vitters wrote:
> On Sat, Dec 15, 2012 at 03:17:05PM -0500, Richard Yao wrote:
>> On 12/15/2012 02:33 PM, Michał Górny wrote:
>>> On Sat, 15 Dec 2012 13:58:43 -0500
>>> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
>>>> On Sat, Dec 15, 2012 at 07:07:09PM +0100, Micha?? G??rny wrote
>>>>> Waaait, what? Did something change lately or are you just repeating
>>>>> the same bullshit for months?
>>>>
>>>>   Older systemd boots OK with a separate /usr and eudev.  But somehow,
>>>> somewhere along the line, as part of the merge, the udev portion of the
>>>> systemd tarball requires initramfs.  See news item...
>>>> http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=36326;list=gentoo
>>>> It was actually finally released 2012-03-16.  If you disagree with that
>>>> news item, complain directly to its author.  If you can boot a udev-181
>>>> or higher system with a separate /usr, and no intrd/initramfs, I'm sure
>>>> a lot of people would be very interested in knowing how.
>>>
>>> This was a Gentoo decision, not an upstream one.
>>
>> If I recall, WilliamH stated at the time that he believed that upstream
>> would make avoiding it increasingly difficult. My impression was that he
>> felt coerced into making that change.
> 
> So systemd still works with a separate /usr and you're continuing to
> spread misinformation. Demonstrating such behaviour while complaining
> about the behaviour of upstream is IMO very ironic.

I believe that the systemd upstream developers would disagree. They
claim is that this is completely broken and any attempt to make it work
(such as what we are discussing) is strongly discouraged.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Olav Vitters]

On Mon, Dec 17, 2012 at 12:09:08PM +0100, Luca Barbato wrote:
> On 12/17/12 11:40 AM, Olav Vitters wrote:
> >So systemd still works with a separate /usr and you're continuing to
> >spread misinformation. Demonstrating such behaviour while complaining
> >about the behaviour of upstream is IMO very ironic.
> 
> No it does not, try by yourself please ^^
> 
> (or just issue and ldd over the main binaries)

I quoted the relevant bits. There has been communication here about it
as well as elsewhere.

What was said here is that systemd did not support this. It does. Now we
can twist words that sometimes "Gentoo" does not mean Gentoo. That
systemd sometimes means as packaged by Gentoo and sometimes upstream.

Poor behaviour!

And yeah, the separate /usr has been mentioned as not to be a problem
(meaning: it works) by the Debian developers when that claim was made on
their list. Furthermore this has found not to be a problem by the Mageia
contributor + QA team. Anyway, this is all happened before this
announcement and the emails in this thread where it was again repeated.
This is a little bit too much IMO to not speak up.

-- 
Regards,
Olav

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

[Richard Yao]

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

On 12/17/2012 08:25 AM, Olav Vitters wrote:
> On Mon, Dec 17, 2012 at 12:09:08PM +0100, Luca Barbato wrote:
>> On 12/17/12 11:40 AM, Olav Vitters wrote:
>>> So systemd still works with a separate /usr and you're continuing to
>>> spread misinformation. Demonstrating such behaviour while complaining
>>> about the behaviour of upstream is IMO very ironic.
>>
>> No it does not, try by yourself please ^^
>>
>> (or just issue and ldd over the main binaries)
> 
> I quoted the relevant bits. There has been communication here about it
> as well as elsewhere.
> 
> What was said here is that systemd did not support this. It does. Now we
> can twist words that sometimes "Gentoo" does not mean Gentoo. That
> systemd sometimes means as packaged by Gentoo and sometimes upstream.
> 
> Poor behaviour!
> 
> And yeah, the separate /usr has been mentioned as not to be a problem
> (meaning: it works) by the Debian developers when that claim was made on
> their list. Furthermore this has found not to be a problem by the Mageia
> contributor + QA team. Anyway, this is all happened before this
> announcement and the emails in this thread where it was again repeated.
> This is a little bit too much IMO to not speak up.
> 

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Olav Vitters]

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

-- 
Regards,
Olav

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

[J. Roeleveld]

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.
This has worked correctly in the past.

The direction udev development is going, according to Lennart, is to make that impossible and he refuses to fix this regression.

I am really happy with this project and intend on testing it once requests for this appear in the eudev mailing list.

--
Joost Roeleveld
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

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

[Greg KH]

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.

But that is a system configuration issue, not a systemd issue, please
don't confuse the two.

> This has worked correctly in the past.

Define "past" please.

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.

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.

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

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

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.

greg k-h

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

[William Hubbs]

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

On Mon, Dec 17, 2012 at 01:31:59PM -0800, 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.
> 
> But that is a system configuration issue, not a systemd issue, please
> don't confuse the two.
> 
> > This has worked correctly in the past.
> 
> Define "past" please.
> 
> 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.
> 
> 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.
> 
> > 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.
> 
> > 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?
 
 This is a very good question.

> 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.
 
This all started with the April 2012 council meeting when it was pushed
through that separate /usr without an initramfs is a supported
configuration, so yes, the previous council started this issue.

Also, yes, eudev believes they will be able to fix it.

I am another one who has been pointing out how this is wrong multiple
times but my statements about it are falling on deaf ears.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Luca Barbato]

On 12/17/12 2:25 PM, Olav Vitters wrote:
> On Mon, Dec 17, 2012 at 12:09:08PM +0100, Luca Barbato wrote:
>> On 12/17/12 11:40 AM, Olav Vitters wrote:
>>> So systemd still works with a separate /usr and you're continuing to
>>> spread misinformation. Demonstrating such behaviour while complaining
>>> about the behaviour of upstream is IMO very ironic.
>>
>> No it does not, try by yourself please ^^
>>
>> (or just issue and ldd over the main binaries)
>
> I quoted the relevant bits. There has been communication here about it
> as well as elsewhere.
>
> What was said here is that systemd did not support this. It does. Now we
> can twist words that sometimes "Gentoo" does not mean Gentoo. That
> systemd sometimes means as packaged by Gentoo and sometimes upstream.
>
> Poor behaviour!

Please do use lld over the systemd binaries, if it reports it linking to 
a library in /usr then you have a problem if /usr is mounted.

One of my main annoyance about systemd is the fact it links to a large 
deal of libraries and that makes it more brittle.

As simple as that, really.

lu

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

[Ulrich Mueller]

>>>>> On Mon, 17 Dec 2012, William Hubbs wrote:

> This all started with the April 2012 council meeting when it was
> pushed through that separate /usr without an initramfs is a
> supported configuration, so yes, the previous council started this
> issue.

Sorry, but that's not an accurate account of what the council has
decided on. What we voted on in the April 2012 meeting was this:

   <ulm> The question is: "Decide on whether a separate /usr is still
         a supported configuration."

And later in the same meeting (yes, I know it's probably not enough
context, so read the full log [1]):

   <ulm> _AxS_: we should make sure that there's reasonable
         documentation about setting up an initramfs though
   <_AxS_> ulm: oh yes -- i was figuring the solution on how to
           support separate /usr with new udev would be tabled at the
           mext meeting (if necessary)
   <Chainsaw> _AxS_: I would recommend raising the implementation
              details for next meeting, yes.
   [...]
   <dberkholz> the implementation details are my concern, but that's
               not the vote.
   <ulm> o.k., that's 5 yes 1 no then

Ulrich

[1] <http://www.gentoo.org/proj/en/council/meeting-logs/20120403.txt>

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

[J. Roeleveld]

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

> But that is a system configuration issue, not a systemd issue, please
> don't confuse the two.

systemd does some interesting things, but I prefer those in a seperate
proces, not in PID-1. But that is a different discussion.

>> 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.
Please provide a simple way to let me see that it is broken on systems
that do not use bluetooth keyboards.
The requirement of having userspace working to have input devices working
seems to be related to bluetooth, not to USB or PS/2 keyboards.

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.

> 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.
Using "mdev" also works.

> 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.
By moving everything into /usr, this brokenness is forced upon users.

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

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

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

--
Joost

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

[Richard Yao]

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

On 12/17/2012 04:31 PM, 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.
> 
> But that is a system configuration issue, not a systemd issue, please
> don't confuse the two.

You can add me to that list. The only difference is that I feel
differently about what the proper solution is. In particular, I reject
the notion that there be a single rules directory. That opens the door
to having a second directory on /usr that enforce the requirement that
rules that depend on /usr execute after /usr is mounted.

>> This has worked correctly in the past.
> 
> Define "past" please.
> 
> 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.
> 
> 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.

In practice, the majority of users have no issues in areas that matter
to them. Those that do seem to be a small minority.

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

It can be said that the systemd developers are not very accommodating to
people who want to pursue alternative solutions.

>> 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?
> 
> 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.
> 
> greg k-h
> 

The systemd developers do not appear to accept patches unless the
patches have direct relevance to Fedora. Many people consider this to be
an upstream issue in the context of that. They likely would not think
such things had the systemd developers said that they would welcome
patches to improve separate /usr support, despite the fact that it would
never be used in any configuration that they care to support. The
disdain that they have expressed toward such configurations provides
validation for such beliefs.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Richard Yao]

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

On 12/17/2012 06:23 PM, William Hubbs wrote:
> On Mon, Dec 17, 2012 at 01:31:59PM -0800, 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.
>>
>> But that is a system configuration issue, not a systemd issue, please
>> don't confuse the two.
>>
>>> This has worked correctly in the past.
>>
>> Define "past" please.
>>
>> 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.
>>
>> 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.
>>
>>> 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.
>>
>>> 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?
>  
>  This is a very good question.
> 
>> 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.
>  
> This all started with the April 2012 council meeting when it was pushed
> through that separate /usr without an initramfs is a supported
> configuration, so yes, the previous council started this issue.
> 
> Also, yes, eudev believes they will be able to fix it.
> 
> I am another one who has been pointing out how this is wrong multiple
> times but my statements about it are falling on deaf ears.
> 
> William
> 

I have also explained how we can fix this multiple times and I can say
that my explanations have been ignored. The eudev project's solution to
this can be summarized in the few sentences that I said in a response to
gregkh (after you wrote your email):

>I reject
>the notion that there be a single rules directory. That opens the door
>to having a second directory on /usr that enforce the requirement that
>rules that depend on /usr execute after /usr is mounted.

The only argument that has been made against it involves libraries that
cross the /usr boundary. I consider such situations to be avoidable.
There has been no other argument made against this approach and I am
quite confident that it is sound. Furthermore, it satisfies the request
of various users to support a separate /usr mount without an initramfs.
Satisfying that seems to me to be a worthwhile goal and it is one that I
and others believe that we can do.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/12/12 06:23 PM, William Hubbs wrote:
> On Mon, Dec 17, 2012 at 01:31:59PM -0800, Greg KH wrote:
>> 
>> 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?
> 
> This is a very good question.

Please!

(that is, after this final clarification of the eudev team's stance)


> 
> Also, yes, eudev believes they will be able to fix it.

No.

1 - The developers of eudev (at least some of us) believe we can push
to at least try and get the various separate-/usr issues fixed via
bugs and patches to the packages that cause them.

2 - Eudev developers believe we can ensure that there is a *udev* that
supports separate-/usr without initramfs.[**]  This doesn't mean that
we think there is any way for udev to fix the whole separate-/usr
issue, but we certainly know that udev can be configured to not cause
it on its own.

3 - There are still many system configurations that have no issues
running with separate-/usr, despite the potential for bugs or
conflicts to occur.  Via #2 we intend to easily allow systems with
such configurations to continue doing it their way.


To summarize, the eudev team knows that breakages caused by
separate-/usr without an initramfs are not trivial and are not
something that changes in eudev will magically fix.  Further, we
acknowledge that separate-/usr support in systemd-udev isn't "broken"
in specific binary terms, either (although the gentoo packages of
~sys-fs/udev-185 through 196-r1 are; sys-fs/udev packaging choices
isn't a conversation we need to re-hash either though).

So I hope the above alleviates the concerns of GregKH, WilliamH and
other respected developers, that the eudev team really is aware of the
complexity of the issues and do not have their heads stuck in the
clouds regarding separate-/usr support.

- ---

** the eudev codebase does need something to compensate for the
removal of the failed rules queue, as that was the method that used to
be leveraged to handle re-running rules that needed something in /usr
when /usr wasn't available.  This is part of what differentiates eudev
from systemd-udev, as this codepatch would most likely fall into the
category of "exotic configurations" for which systemd plans to reject
patches.

For more eudev-specific discussion, especially development or
technical discussions, please join us on eudev@gentoo.org rather than
- -dev@

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDQsNQACgkQ2ugaI38ACPBJ7wD9H9x4olYqGM9OhcL1Xmi07F8O
vWjadBlDyruC4YiTJqcA/jwd+YxNMSB2CA/0XWVD88aOzkJUJs3LK6lT/owIOeFg
=1OT9
-----END PGP SIGNATURE-----

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

[William Hubbs]

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

On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
> >>>>> On Mon, 17 Dec 2012, William Hubbs wrote:
> 
> > This all started with the April 2012 council meeting when it was
> > pushed through that separate /usr without an initramfs is a
> > supported configuration, so yes, the previous council started this
> > issue.
> 
> Sorry, but that's not an accurate account of what the council has
> decided on. What we voted on in the April 2012 meeting was this:
> 
>    <ulm> The question is: "Decide on whether a separate /usr is still
>          a supported configuration."
 
Ulrich,

 I have read the log, and that is where the confusion is.

 If that is true, and I think folks would beg to differ, we can say that
 the way separate /usr is supported is via requiring an initramfs and
 move forward from there because that would still be within the
 council's requirement since there is now documentation on how to build
 an initramfs.

I know at least one council member who was at that meeting who would
strongly disagree and say that what you voted for was that separate
/usr, without an initramfs, is a supported configuration.

Thoughts?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Richard Yao]

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

On 12/18/2012 01:45 PM, William Hubbs wrote:
> On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
>>>>>>> On Mon, 17 Dec 2012, William Hubbs wrote:
>>
>>> This all started with the April 2012 council meeting when it was
>>> pushed through that separate /usr without an initramfs is a
>>> supported configuration, so yes, the previous council started this
>>> issue.
>>
>> Sorry, but that's not an accurate account of what the council has
>> decided on. What we voted on in the April 2012 meeting was this:
>>
>>    <ulm> The question is: "Decide on whether a separate /usr is still
>>          a supported configuration."
>  
> Ulrich,
> 
>  I have read the log, and that is where the confusion is.
> 
>  If that is true, and I think folks would beg to differ, we can say that
>  the way separate /usr is supported is via requiring an initramfs and
>  move forward from there because that would still be within the
>  council's requirement since there is now documentation on how to build
>  an initramfs.
> 
> I know at least one council member who was at that meeting who would
> strongly disagree and say that what you voted for was that separate
> /usr, without an initramfs, is a supported configuration.
> 
> Thoughts?
> 
> William
> 

Our official documentation for LVM2 explicitly advised users to use such
configurations. Dropping support now will break existing systems
unnecessarily.

Before anyone says to use a news item, let me say that publishing a news
item to inform users that we decided to break their systems will not
make it better.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[William Hubbs]

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

On Tue, Dec 18, 2012 at 01:51:27PM -0500, Richard Yao wrote:
> On 12/18/2012 01:45 PM, William Hubbs wrote:
> > On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
> >>>>>>> On Mon, 17 Dec 2012, William Hubbs wrote:
> >>
> >>> This all started with the April 2012 council meeting when it was
> >>> pushed through that separate /usr without an initramfs is a
> >>> supported configuration, so yes, the previous council started this
> >>> issue.
> >>
> >> Sorry, but that's not an accurate account of what the council has
> >> decided on. What we voted on in the April 2012 meeting was this:
> >>
> >>    <ulm> The question is: "Decide on whether a separate /usr is still
> >>          a supported configuration."
> >  
> > Ulrich,
> > 
> >  I have read the log, and that is where the confusion is.
> > 
> >  If that is true, and I think folks would beg to differ, we can say that
> >  the way separate /usr is supported is via requiring an initramfs and
> >  move forward from there because that would still be within the
> >  council's requirement since there is now documentation on how to build
> >  an initramfs.
> > 
> > I know at least one council member who was at that meeting who would
> > strongly disagree and say that what you voted for was that separate
> > /usr, without an initramfs, is a supported configuration.
> > 
> > Thoughts?
> > 
> > William
> > 
> 
> Our official documentation for LVM2 explicitly advised users to use such
> configurations. Dropping support now will break existing systems
> unnecessarily.
> 
> Before anyone says to use a news item, let me say that publishing a news
> item to inform users that we decided to break their systems will not
> make it better.

I don't follow. The initramfs document [1] clearly points out that if
you have lvm you have to include it when you run genkernel, and we can't
move forward until a proper version of genkernel is stable.

William

[1] http://www.gentoo.org/doc/en/initramfs-guide.xml

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/12/12 01:45 PM, William Hubbs wrote:
> On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
>>>>>>> On Mon, 17 Dec 2012, William Hubbs wrote:
>> 
>>> This all started with the April 2012 council meeting when it
>>> was pushed through that separate /usr without an initramfs is
>>> a supported configuration, so yes, the previous council started
>>> this issue.
>> 
>> Sorry, but that's not an accurate account of what the council
>> has decided on. What we voted on in the April 2012 meeting was
>> this:
>> 
>> <ulm> The question is: "Decide on whether a separate /usr is
>> still a supported configuration."
> 
> Ulrich,
> 
> I have read the log, and that is where the confusion is.
> 
> If that is true, and I think folks would beg to differ, we can say
> that the way separate /usr is supported is via requiring an
> initramfs and move forward from there because that would still be
> within the council's requirement since there is now documentation
> on how to build an initramfs.
> 
> I know at least one council member who was at that meeting who
> would strongly disagree and say that what you voted for was that
> separate /usr, without an initramfs, is a supported configuration.


There was at least one council member that said they would not accept
an initramfs solution as the only way to support separate-/usr, but
having also been there I believe the vote itself was still that
"separate /usr will be supported" period.

So yes, a proper initramfs solution including documentation would
suffice for this April meeting decision.  This however rolls forward
to the October council meeting and it's decision to wait and/or not
officially adopt a "separate-/usr is only supported through an
initramfs" policy.  (The decision at that meeting was rather
complicated so i'm not really trying to summarize it but rather just
reference that it happened)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDQweAACgkQ2ugaI38ACPAApAD+JDWX90fnT3IL2aYitnLO8Kiz
JF9+0NxbDy3tr/gHeHkA/3WnBWrl14tsMQKyB5IlHv445BJFFouMKMQId4xznhEi
=bUdE
-----END PGP SIGNATURE-----

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

[Rich Freeman]

On Tue, Dec 18, 2012 at 1:45 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
>> >>>>> On Mon, 17 Dec 2012, William Hubbs wrote:
>>
>> > This all started with the April 2012 council meeting when it was
>> > pushed through that separate /usr without an initramfs is a
>> > supported configuration, so yes, the previous council started this
>> > issue.
>>
>> Sorry, but that's not an accurate account of what the council has
>> decided on. What we voted on in the April 2012 meeting was this:
>>
>>    <ulm> The question is: "Decide on whether a separate /usr is still
>>          a supported configuration."
>
> I know at least one council member who was at that meeting who would
> strongly disagree and say that what you voted for was that separate
> /usr, without an initramfs, is a supported configuration.

Does it really matter?  We're arguing over what the council decided
six months ago, and they never really took a clear vote (I see lots of
discussion, and no motion followed by aye/nay's).  I would certainly
recommend in the future that if the Council wants to set some kind of
policy that they make a clear statement of the policy followed by a
simple yes/no vote.  However, there is little value in going back over
that particular decision.

This whole thread really seems like a major waste of hot air.  Does it
really matter whether udev supports a separate /usr or not?  If your
system works, then good for you.  If it doesn't work, then install an
initramfs, or use something other than udev, and if that fixes your
probably great.  Just don't talk about it here, or you'll have 400
people telling you that you're wrong.

If you think that eudev is a big waste of time, then don't use it.

Rich

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

[Greg KH]

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

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

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

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

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

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

> Using "mdev" also works.

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

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

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

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

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

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

greg k-h

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

[Kevin Chadwick]

On Wed, 19 Dec 2012 09:13:28 -0800
Greg KH <gregkh@gentoo.org> wrote:

> 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

If either of those links allowed comments, the story they told would be
very different.

From memory notice how the second link skimps over the main driving
force (point 4 again from memory).

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

[J. Roeleveld]

[-- 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 --]

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

[Michał Górny]

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

On Thu, 20 Dec 2012 00:27:26 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

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

Are you aware that these environments are actually one of the most
important reasons for moving everything to /usr? I don't know what
hackery you're using to keep the systems in sync and working but it is
braindead enough.

The difference between keeping part of the system in rootfs
and initramfs is that you can discard initramfs after using it. It can
be anything which is enough to get the /usr mounted and system
starting. Files on rootfs *have* to be in sync with those on /usr
or you're getting random failures.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Richard Yao]

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

On 12/20/2012 03:31 AM, Michał Górny wrote:
> On Thu, 20 Dec 2012 00:27:26 +0100
> "J. Roeleveld" <joost@antarean.org> wrote:
> 
>> 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?
> 
> Are you aware that these environments are actually one of the most
> important reasons for moving everything to /usr? I don't know what
> hackery you're using to keep the systems in sync and working but it is
> braindead enough.
> 
> The difference between keeping part of the system in rootfs
> and initramfs is that you can discard initramfs after using it. It can
> be anything which is enough to get the /usr mounted and system
> starting. Files on rootfs *have* to be in sync with those on /usr
> or you're getting random failures.
> 

No one has proposed moving everything to /usr. At the minimum, we would
still have /etc and /var in /, as well as various mountpoints. If we do
move those to /usr, then we effectively renamed / to /usr, which is
pointless. The absurdity of mounting /usr over NFS instead of / is
precisely why people are saying to just mount / (with /usr as being part
of it).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Rich Freeman]

On Thu, Dec 20, 2012 at 6:21 AM, Richard Yao <ryao@gentoo.org> wrote:
> No one has proposed moving everything to /usr. At the minimum, we would
> still have /etc and /var in /, as well as various mountpoints. If we do
> move those to /usr, then we effectively renamed / to /usr, which is
> pointless. The absurdity of mounting /usr over NFS instead of / is
> precisely why people are saying to just mount / (with /usr as being part
> of it).

We're drifting here, but the concept is that machine-local stuff like
configuration stays out of /usr, and generic distro stuff stays in
/usr.

A webserver for site1 vs site2 would be identical in /usr, but
different elsewhere.

However, that whole approach makes less sense for a distro that prides
itself on you being able to make every installation unique.  That
said, if you do want to make a whole bunch of Gentoo installs the same
then sticking everything important in /usr and network mounting it is
a good way to accomplish it.

Rich

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

[Richard Yao]

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

On 12/20/2012 07:02 AM, Rich Freeman wrote:
> On Thu, Dec 20, 2012 at 6:21 AM, Richard Yao <ryao@gentoo.org> wrote:
>> No one has proposed moving everything to /usr. At the minimum, we would
>> still have /etc and /var in /, as well as various mountpoints. If we do
>> move those to /usr, then we effectively renamed / to /usr, which is
>> pointless. The absurdity of mounting /usr over NFS instead of / is
>> precisely why people are saying to just mount / (with /usr as being part
>> of it).
> 
> We're drifting here, but the concept is that machine-local stuff like
> configuration stays out of /usr, and generic distro stuff stays in
> /usr.
> 
> A webserver for site1 vs site2 would be identical in /usr, but
> different elsewhere.
> 
> However, that whole approach makes less sense for a distro that prides
> itself on you being able to make every installation unique.  That
> said, if you do want to make a whole bunch of Gentoo installs the same
> then sticking everything important in /usr and network mounting it is
> a good way to accomplish it.
> 
> Rich
> 

You could accomplish a similar effect at the NFS server via a stacking
filesystem, with the advantage being that all configuration data would
be stored remotely.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Kevin Chadwick]

> We're drifting here, but the concept is that machine-local stuff like
> configuration stays out of /usr, and generic distro stuff stays in
> /usr.
> 
> A webserver for site1 vs site2 would be identical in /usr, but
> different elsewhere.

That has always been the case. In fact people have tried to
seperate /etc from / but it has proved too problematic. That's a
different issue entirely. If the proposal was / (etc) /root /usr. I
would be happy... if it worked.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[J. Roeleveld]

On Thursday, December 20, 2012 09:31:36 AM Michał Górny wrote:
> On Thu, 20 Dec 2012 00:27:26 +0100
> 
> "J. Roeleveld" <joost@antarean.org> wrote:
> > 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?
> 
> Are you aware that these environments are actually one of the most
> important reasons for moving everything to /usr? I don't know what
> hackery you're using to keep the systems in sync and working but it is
> braindead enough.

An init* needs to be kept in sync with the rest of the system as well. As that 
is a compressed filesystem, it takes a lot more effort to keep that in sync in 
comparison to a "normal" filesystem.
I consider having to write scripts to unpack, modify and repack an init* to be 
more hackery then to keep a bootable root-filesystem working that can mount 
all the filesystems needed for the whole environment.
Anything needed to mount /usr, /var, /run (and any other part needed for the 
boot-process) should not be allowed to depend on anything in any of those 
directories prior to those being mountable.

> The difference between keeping part of the system in rootfs
> and initramfs is that you can discard initramfs after using it. It can
> be anything which is enough to get the /usr mounted and system
> starting. Files on rootfs *have* to be in sync with those on /usr
> or you're getting random failures.

The same is true for an init*.
If an update of part of the OS leads to subtle changes in the filesystem where 
older versions can no longer properly access them, the init* is broken.

--
Joost

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

[J. Roeleveld]

On Thursday, December 20, 2012 07:02:06 AM Rich Freeman wrote:
> On Thu, Dec 20, 2012 at 6:21 AM, Richard Yao <ryao@gentoo.org> wrote:
> > No one has proposed moving everything to /usr. At the minimum, we would
> > still have /etc and /var in /, as well as various mountpoints. If we do
> > move those to /usr, then we effectively renamed / to /usr, which is
> > pointless. The absurdity of mounting /usr over NFS instead of / is
> > precisely why people are saying to just mount / (with /usr as being part
> > of it).
> 
> We're drifting here, but the concept is that machine-local stuff like
> configuration stays out of /usr, and generic distro stuff stays in
> /usr.
> 
> A webserver for site1 vs site2 would be identical in /usr, but
> different elsewhere.

It would be identical everywhere but on:
/etc/apache
/var/www
(using default locations)

I would actually put /var/www on the share as well and use symlinks from 
/etc/apache to point to the specific vhost-config files. That way I could 
quickly move websites to a different node when I'd need to take one down for 
maintenance.

Having only /usr shared betweehn those wouldn't be sufficient and would make 
patching and updates more risky as I would then be updating the whole 
environment at once.

> However, that whole approach makes less sense for a distro that prides
> itself on you being able to make every installation unique.  That
> said, if you do want to make a whole bunch of Gentoo installs the same
> then sticking everything important in /usr and network mounting it is
> a good way to accomplish it.

How does portage handle a situation like this?
Would I be able to use emerge on any node to add additional software along 
with all the config-file changes?

If we take the webserver examples:
The software is under /usr
The configuration is under /etc/apache

If I update apache and there are additional options and/or changes to the 
config files, how do I migrate those to all the different nodes?
If the config is the same on all nodes, why not simply share the " / " ?
If it differs, I then need to write down all the new options and go through 
every single node and update the config there.

The same is true with any other environment where multiple nodes are used for 
the same purpose.

For the usecases that I generally deal with, the only time where a shared /usr 
would make sense is when I select " Install everything " during the install.
I used to do that to avoid having to deal with RPM-dependencies when I was 
using Redhat.

--
Joost

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

[Michał Górny]

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

On Fri, 21 Dec 2012 09:10:22 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

> On Thursday, December 20, 2012 09:31:36 AM Michał Górny wrote:
> > On Thu, 20 Dec 2012 00:27:26 +0100
> > 
> > "J. Roeleveld" <joost@antarean.org> wrote:
> > > 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?
> > 
> > Are you aware that these environments are actually one of the most
> > important reasons for moving everything to /usr? I don't know what
> > hackery you're using to keep the systems in sync and working but it is
> > braindead enough.
> 
> An init* needs to be kept in sync with the rest of the system as well. As that 
> is a compressed filesystem, it takes a lot more effort to keep that in sync in 
> comparison to a "normal" filesystem.
> I consider having to write scripts to unpack, modify and repack an init* to be 
> more hackery then to keep a bootable root-filesystem working that can mount 
> all the filesystems needed for the whole environment.
> Anything needed to mount /usr, /var, /run (and any other part needed for the 
> boot-process) should not be allowed to depend on anything in any of those 
> directories prior to those being mountable.
> 
> > The difference between keeping part of the system in rootfs
> > and initramfs is that you can discard initramfs after using it. It can
> > be anything which is enough to get the /usr mounted and system
> > starting. Files on rootfs *have* to be in sync with those on /usr
> > or you're getting random failures.
> 
> The same is true for an init*.
> If an update of part of the OS leads to subtle changes in the filesystem where 
> older versions can no longer properly access them, the init* is broken.

Just let me know when you have to maintain a lot of such systemd
and upgrade, say, glibc. Then maybe you'll understand.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[J. Roeleveld]

On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
> On Fri, 21 Dec 2012 09:10:22 +0100
> 
> "J. Roeleveld" <joost@antarean.org> wrote:
> > On Thursday, December 20, 2012 09:31:36 AM Michał Górny wrote:
> > > On Thu, 20 Dec 2012 00:27:26 +0100
> > > 
> > > "J. Roeleveld" <joost@antarean.org> wrote:
> > > > 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?
> > > 
> > > Are you aware that these environments are actually one of the most
> > > important reasons for moving everything to /usr? I don't know what
> > > hackery you're using to keep the systems in sync and working but it is
> > > braindead enough.
> > 
> > An init* needs to be kept in sync with the rest of the system as well. As
> > that is a compressed filesystem, it takes a lot more effort to keep that
> > in sync in comparison to a "normal" filesystem.
> > I consider having to write scripts to unpack, modify and repack an init*
> > to be more hackery then to keep a bootable root-filesystem working that
> > can mount all the filesystems needed for the whole environment.
> > Anything needed to mount /usr, /var, /run (and any other part needed for
> > the boot-process) should not be allowed to depend on anything in any of
> > those directories prior to those being mountable.
> > 
> > > The difference between keeping part of the system in rootfs
> > > and initramfs is that you can discard initramfs after using it. It can
> > > be anything which is enough to get the /usr mounted and system
> > > starting. Files on rootfs *have* to be in sync with those on /usr
> > > or you're getting random failures.
> > 
> > The same is true for an init*.
> > If an update of part of the OS leads to subtle changes in the filesystem
> > where older versions can no longer properly access them, the init* is
> > broken.
> Just let me know when you have to maintain a lot of such systemd
> and upgrade, say, glibc. Then maybe you'll understand.

A shared /usr means I need to update ALL the systems at once.
When /usr is not shared, I can update groups at a time.

To save time, a shared filesystem containing binary packages can easily be 
used and this is what I use myself.
I have one VM that is used to rebuild the packages when I want to do an update 
and the real host then simply uses the binary packages.
The configuration items needed for emerge are synchronized between the build 
system and the actual server.

The main reason why I would never share an OS filesystem between multiple 
systems is to avoid the situation where a failed upgrade takes down the entire 
environment.
And a shared OS filesystem also introduces a very nice Single Point of 
Failure. What will happen when the NFS-server (or whatever is used) goes down 
for whatever reason?

In other words, to make an environment that has a very nice single point of 
failure possible, existing working environments are classed as "broken".

--
Joost

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

[Michał Górny]

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

On Fri, 21 Dec 2012 11:24:45 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

> On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
> > Just let me know when you have to maintain a lot of such systemd
> > and upgrade, say, glibc. Then maybe you'll understand.
> 
> A shared /usr means I need to update ALL the systems at once.
> When /usr is not shared, I can update groups at a time.

Yes, and this is what disqualifies it for the general case. If you
can't update one at some point, you can't update the others or it is
going to likely get broken in a random manner.

> To save time, a shared filesystem containing binary packages can easily be 
> used and this is what I use myself.
> I have one VM that is used to rebuild the packages when I want to do an update 
> and the real host then simply uses the binary packages.
> The configuration items needed for emerge are synchronized between the build 
> system and the actual server.

Wait, wait. So you have introduced even more hackery to get it working?
Good to hear. That's really a good reason to support your arguments.
'I got it working with a lot of hackery, so it is a good solution!'

> The main reason why I would never share an OS filesystem between multiple 
> systems is to avoid the situation where a failed upgrade takes down the entire 
> environment.

And this doesn't happen in your case because...? Because as far as I
can see:

1) failed upgrade in /usr takes down the entire environment,

2) failed upgrade in / may take down the machine,

3) failed hackery you're doing to get it all working may have even more
unpredictable results.

And yes, I prefer to take down the entire environment and fix it in one
step. That sounds much better than trying to get it back up and re-sync
all the machines which got into some mid-broken state.

> And a shared OS filesystem also introduces a very nice Single Point of 
> Failure. What will happen when the NFS-server (or whatever is used) goes down 
> for whatever reason?

And what is the difference now? Is it another argument like 'hey, i can
still see the command-line, so it's better. not that i can do anything
useful with it.'

> In other words, to make an environment that has a very nice single point of 
> failure possible, existing working environments are classed as "broken".

NFS-shared system does classify as 'a single point of failure'.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[J. Roeleveld]

On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
> On Fri, 21 Dec 2012 11:24:45 +0100
> 
> "J. Roeleveld" <joost@antarean.org> wrote:
> > On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
> > > Just let me know when you have to maintain a lot of such systemd
> > > and upgrade, say, glibc. Then maybe you'll understand.
> > 
> > A shared /usr means I need to update ALL the systems at once.
> > When /usr is not shared, I can update groups at a time.
> 
> Yes, and this is what disqualifies it for the general case. If you
> can't update one at some point, you can't update the others or it is
> going to likely get broken in a random manner.

Yes, but do you want to find out when the entire production environment is 
down? Or would you rather do the upgrades in steps and only risk having to 
rebuild a few nodes and have a lower performance during that time?
There is a big difference between 50% performance and 0%.

> > To save time, a shared filesystem containing binary packages can easily be
> > used and this is what I use myself.
> > I have one VM that is used to rebuild the packages when I want to do an
> > update and the real host then simply uses the binary packages.
> > The configuration items needed for emerge are synchronized between the
> > build system and the actual server.
> 
> Wait, wait. So you have introduced even more hackery to get it working?
> Good to hear. That's really a good reason to support your arguments.
> 'I got it working with a lot of hackery, so it is a good solution!'

Please explain, what is hackery about having a single host doing all the 
compiling for multiple servers?
The only thing I need to synchronize between the "real" host and the "compile" 
host is "/etc/portage" and "/var/lib/portage/world"

I don't need any of those to keep the environment running. It's only needed 
during the install/update steps.

> > The main reason why I would never share an OS filesystem between multiple
> > systems is to avoid the situation where a failed upgrade takes down the
> > entire environment.
> 
> And this doesn't happen in your case because...? Because as far as I
> can see:
> 
> 1) failed upgrade in /usr takes down the entire environment,
> 
> 2) failed upgrade in / may take down the machine,
> 
> 3) failed hackery you're doing to get it all working may have even more
> unpredictable results.
> 
> And yes, I prefer to take down the entire environment and fix it in one
> step. That sounds much better than trying to get it back up and re-sync
> all the machines which got into some mid-broken state.

With shared OS filesystems, that is what you will get.
With non-shared OS filesystems, the other nodes will keep working.

> > And a shared OS filesystem also introduces a very nice Single Point of
> > Failure. What will happen when the NFS-server (or whatever is used) goes
> > down for whatever reason?
> 
> And what is the difference now? Is it another argument like 'hey, i can
> still see the command-line, so it's better. not that i can do anything
> useful with it.'

Actually, with a shared OS-filesystem:
When it goes down: "Oops, we lost the entire environment"

With non-shared:
One node goes down: "Oops, we need to fix this node, performance will be down 
while we fix this"
Or "this and that app won't work, but the rest still does"

That's the difference between a major outage impacting the entire company or 
one that only affects a few departments.

> > In other words, to make an environment that has a very nice single point
> > of
> > failure possible, existing working environments are classed as "broken".
> 
> NFS-shared system does classify as 'a single point of failure'.

If a single shared filesystem is necessary to be able to use the entire 
environment, then yes.

--
Joost

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

[Michał Górny]

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

On Fri, 21 Dec 2012 12:31:28 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

> On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
> > On Fri, 21 Dec 2012 11:24:45 +0100
> > 
> > "J. Roeleveld" <joost@antarean.org> wrote:
> > > On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
> > > > Just let me know when you have to maintain a lot of such systemd
> > > > and upgrade, say, glibc. Then maybe you'll understand.
> > > 
> > > A shared /usr means I need to update ALL the systems at once.
> > > When /usr is not shared, I can update groups at a time.
> > 
> > Yes, and this is what disqualifies it for the general case. If you
> > can't update one at some point, you can't update the others or it is
> > going to likely get broken in a random manner.
> 
> Yes, but do you want to find out when the entire production environment is 
> down? Or would you rather do the upgrades in steps and only risk having to 
> rebuild a few nodes and have a lower performance during that time?
> There is a big difference between 50% performance and 0%.

Didn't you just state that you *have* to update all at the same time?

> > > To save time, a shared filesystem containing binary packages can easily be
> > > used and this is what I use myself.
> > > I have one VM that is used to rebuild the packages when I want to do an
> > > update and the real host then simply uses the binary packages.
> > > The configuration items needed for emerge are synchronized between the
> > > build system and the actual server.
> > 
> > Wait, wait. So you have introduced even more hackery to get it working?
> > Good to hear. That's really a good reason to support your arguments.
> > 'I got it working with a lot of hackery, so it is a good solution!'
> 
> Please explain, what is hackery about having a single host doing all the 
> compiling for multiple servers?
> The only thing I need to synchronize between the "real" host and the "compile" 
> host is "/etc/portage" and "/var/lib/portage/world"

The hackery is about installing packages partially to local
and partially to shared location. I feel like I'm not following anymore
what actually happens there, not that it is worth my time.

> > > The main reason why I would never share an OS filesystem between multiple
> > > systems is to avoid the situation where a failed upgrade takes down the
> > > entire environment.
> > 
> > And this doesn't happen in your case because...? Because as far as I
> > can see:
> > 
> > 1) failed upgrade in /usr takes down the entire environment,
> > 
> > 2) failed upgrade in / may take down the machine,
> > 
> > 3) failed hackery you're doing to get it all working may have even more
> > unpredictable results.
> > 
> > And yes, I prefer to take down the entire environment and fix it in one
> > step. That sounds much better than trying to get it back up and re-sync
> > all the machines which got into some mid-broken state.
> 
> With shared OS filesystems, that is what you will get.
> With non-shared OS filesystems, the other nodes will keep working.

Aren't we talking about shared OS filesystems *right now*?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[J. Roeleveld]

On Friday, December 21, 2012 12:42:23 PM Michał Górny wrote:
> On Fri, 21 Dec 2012 12:31:28 +0100
> 
> "J. Roeleveld" <joost@antarean.org> wrote:
> > On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
> > > On Fri, 21 Dec 2012 11:24:45 +0100
> > > 
> > > "J. Roeleveld" <joost@antarean.org> wrote:
> > > > On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
> > > > > Just let me know when you have to maintain a lot of such systemd
> > > > > and upgrade, say, glibc. Then maybe you'll understand.
> > > > 
> > > > A shared /usr means I need to update ALL the systems at once.
> > > > When /usr is not shared, I can update groups at a time.
> > > 
> > > Yes, and this is what disqualifies it for the general case. If you
> > > can't update one at some point, you can't update the others or it is
> > > going to likely get broken in a random manner.
> > 
> > Yes, but do you want to find out when the entire production environment is
> > down? Or would you rather do the upgrades in steps and only risk having to
> > rebuild a few nodes and have a lower performance during that time?
> > There is a big difference between 50% performance and 0%.
> 
> Didn't you just state that you *have* to update all at the same time?

Please re-read what I wrote.
I said, with a *shared* /usr, then yes, I do need to update the entire 
environment at the same time.
With a *non-shared*, this is not necessary.

I also stated that that is one of the reasons why I do not *want* to share 
/usr between multiple hosts.

> > > > To save time, a shared filesystem containing binary packages can
> > > > easily be
> > > > used and this is what I use myself.
> > > > I have one VM that is used to rebuild the packages when I want to do
> > > > an
> > > > update and the real host then simply uses the binary packages.
> > > > The configuration items needed for emerge are synchronized between the
> > > > build system and the actual server.
> > > 
> > > Wait, wait. So you have introduced even more hackery to get it working?
> > > Good to hear. That's really a good reason to support your arguments.
> > > 'I got it working with a lot of hackery, so it is a good solution!'
> > 
> > Please explain, what is hackery about having a single host doing all the
> > compiling for multiple servers?
> > The only thing I need to synchronize between the "real" host and the
> > "compile" host is "/etc/portage" and "/var/lib/portage/world"
> 
> The hackery is about installing packages partially to local
> and partially to shared location. I feel like I'm not following anymore
> what actually happens there, not that it is worth my time.

That type of hackery is what I do *not* do. Please see above.

> > > > The main reason why I would never share an OS filesystem between
> > > > multiple
> > > > systems is to avoid the situation where a failed upgrade takes down
> > > > the
> > > > entire environment.
> > > 
> > > And this doesn't happen in your case because...? Because as far as I
> > > can see:
> > > 
> > > 1) failed upgrade in /usr takes down the entire environment,
> > > 
> > > 2) failed upgrade in / may take down the machine,
> > > 
> > > 3) failed hackery you're doing to get it all working may have even more
> > > unpredictable results.
> > > 
> > > And yes, I prefer to take down the entire environment and fix it in one
> > > step. That sounds much better than trying to get it back up and re-sync
> > > all the machines which got into some mid-broken state.
> > 
> > With shared OS filesystems, that is what you will get.
> > With non-shared OS filesystems, the other nodes will keep working.
> 
> Aren't we talking about shared OS filesystems *right now*?

Yes, as a reason why *not* to do it.

I don't ever intend to use a shared OS filesystem. That includes not sharing 
/usr because of the reasons I mentioned.

The main reason mentioned for moving everything and the kitchen sink into /usr 
is to make it easier to share /usr between multiple servers.
Doing that has the side-effect that a seperate /usr will not work without an 
init*.

This makes me conclude that a decision has been made to:
Break existing working environments to support an environment that has a 
built-in single point of failure.

--
Joost

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/12/12 03:10 AM, J. Roeleveld wrote:

> An init* needs to be kept in sync with the rest of the system as
> well.


Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDUaU0ACgkQ2ugaI38ACPDLLgEAuEUaZF8nCeC2B1QC8MC5ItRh
xXE7v2Heu7bh54yOfWEA/jc1LOBtb/Al+uBvO39NfscdY8wO5X7HJ/Vbh9t/hwTg
=abYV
-----END PGP SIGNATURE-----

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

[J. Roeleveld]

On Friday, December 21, 2012 08:51:09 AM Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 21/12/12 03:10 AM, J. Roeleveld wrote:
> > An init* needs to be kept in sync with the rest of the system as
> > well.
> 
> Just to be clear, by "init*" you mean {initrd,initramfs} , correct?

Yes

On the Gentoo-user mailing list, that's one of the two common ways of 
referring to it. The other one is " init-thingy ". ;)

--
Joost

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

[Rich Freeman]

On Fri, Dec 21, 2012 at 8:51 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> On 21/12/12 03:10 AM, J. Roeleveld wrote:
>
>> An init* needs to be kept in sync with the rest of the system as
>> well.
>
> Just to be clear, by "init*" you mean {initrd,initramfs} , correct?

Seems likely.

However, for the most part it really only needs to be kept in sync
with the kernel.  Smarter ones like dracut that might do things like
keep a copy of mdadm.conf internally might need to be updated when
your disks change, and so on.  In general, however, they only need
changes when either your kernel changes, or the path to the root
filesystem changes (by path I mean mdadm/lvm/nfs/etc).

Everything inside the initramfs is self-contained and does not have
dependencies on anything outside.  Sure, it might not have the latest
version of udev inside or whatever, but unless you need the latest
version of udev to mount root it isn't a problem.  The contents of the
initramfs are generally discarded once root and /usr are mounted.

However, I can vouch that an initramfs can make things interesting if
you do move your root filesystem.  I just moved mine to lvm and forgot
to update fstab.sys.  Dracut does pay attention to your root
filesystem in fstab and fstab.sys - it uses the kernel line to find
root, but once it is mounted fstab gets read and used to remount it.
Oh, and if fstab and fstab.sys have differing root lines both get
sort-of-mounted (it mounts what is in fstab, and then mounts fstab.sys
over it as far as I can tell - running mount and finding that you have
/sysroot mounted on a mountpoint that you can't even get to is fun).

But, I wouldn't be running root on lvm but for the initramfs, so it
was worth the trouble.  Anybody who moves around root without a boot
CD handy is asking for trouble anyway.

Rich

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

[Dale]

J. Roeleveld wrote:
> On Friday, December 21, 2012 08:51:09 AM Ian Stakenvicius wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 21/12/12 03:10 AM, J. Roeleveld wrote:
>>> An init* needs to be kept in sync with the rest of the system as
>>> well.
>> Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
> Yes
>
> On the Gentoo-user mailing list, that's one of the two common ways of 
> referring to it. The other one is " init-thingy ". ;)
>
> --
> Joost
>
>

I plead guilty on starting this one.  It was I.  Joost, point your
fingers at me.  It's OK. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

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

[J. Roeleveld]

On Friday, December 21, 2012 08:52:00 AM Dale wrote:
> J. Roeleveld wrote:
> > On Friday, December 21, 2012 08:51:09 AM Ian Stakenvicius wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >> 
> >> On 21/12/12 03:10 AM, J. Roeleveld wrote:
> >>> An init* needs to be kept in sync with the rest of the system as
> >>> well.
> >> 
> >> Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
> > 
> > Yes
> > 
> > On the Gentoo-user mailing list, that's one of the two common ways of
> > referring to it. The other one is " init-thingy ". ;)
> > 
> > --
> > Joost
> 
> I plead guilty on starting this one.  It was I.  Joost, point your
> fingers at me.  It's OK.

Dale, you may have invented the word " init-thingy ", but others have started 
to copy it :)

--
Joost

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

[J. Roeleveld]

On Friday, December 21, 2012 09:38:36 AM Rich Freeman wrote:
> On Fri, Dec 21, 2012 at 8:51 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> > On 21/12/12 03:10 AM, J. Roeleveld wrote:
> >> An init* needs to be kept in sync with the rest of the system as
> >> well.
> > 
> > Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
> 
> Seems likely.
> 
> However, for the most part it really only needs to be kept in sync
> with the kernel.  Smarter ones like dracut that might do things like
> keep a copy of mdadm.conf internally might need to be updated when
> your disks change, and so on.  In general, however, they only need
> changes when either your kernel changes, or the path to the root
> filesystem changes (by path I mean mdadm/lvm/nfs/etc).

And with the "move to /usr", also when that changes.
Granted, on most systems it won't actually move often once it's installed.

> Everything inside the initramfs is self-contained and does not have
> dependencies on anything outside.  Sure, it might not have the latest
> version of udev inside or whatever, but unless you need the latest
> version of udev to mount root it isn't a problem.  The contents of the
> initramfs are generally discarded once root and /usr are mounted.

True, but what if a system has been updated and the structure of the system 
has been changed. This makes the init* (what is the preferred way of naming 
this?) no longer able to boot properly.

> However, I can vouch that an initramfs can make things interesting if
> you do move your root filesystem.  I just moved mine to lvm and forgot
> to update fstab.sys.  Dracut does pay attention to your root
> filesystem in fstab and fstab.sys - it uses the kernel line to find
> root, but once it is mounted fstab gets read and used to remount it.
> Oh, and if fstab and fstab.sys have differing root lines both get
> sort-of-mounted (it mounts what is in fstab, and then mounts fstab.sys
> over it as far as I can tell - running mount and finding that you have
> /sysroot mounted on a mountpoint that you can't even get to is fun).

Why are there 2 fstab-files? That, to me, looks like a likely cause for 
problems.
I haven't tried dracut yet, but have tried " genkernel " to generate the init* 
and it does work. However it does increase the complexity and adds a layer 
that is not easily debugged.
I am looking forward to when eudev is released and supports my environment so 
I can get rid of it.

The creation of init*-files is not clearly documented and the tools available 
want to put user-space tools inside it.

> But, I wouldn't be running root on lvm but for the initramfs, so it
> was worth the trouble.  Anybody who moves around root without a boot
> CD handy is asking for trouble anyway.

Agreed, I would do that move from inside a rescue-environment myself, not on a 
live system :)

--
Joost

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

[Dale]

J. Roeleveld wrote:
> On Friday, December 21, 2012 08:52:00 AM Dale wrote:
>> J. Roeleveld wrote:
>>> On Friday, December 21, 2012 08:51:09 AM Ian Stakenvicius wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> On 21/12/12 03:10 AM, J. Roeleveld wrote:
>>>>> An init* needs to be kept in sync with the rest of the system as
>>>>> well.
>>>> Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
>>> Yes
>>>
>>> On the Gentoo-user mailing list, that's one of the two common ways of
>>> referring to it. The other one is " init-thingy ". ;)
>>>
>>> --
>>> Joost
>> I plead guilty on starting this one.  It was I.  Joost, point your
>> fingers at me.  It's OK.
> Dale, you may have invented the word " init-thingy ", but others have started 
> to copy it :)
>
> --
> Joost
>
>


That name is better than what I would like to call it.  o_O 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

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

[Stelian Ionescu]

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

On Fri, 2012-12-21 at 12:48 +0100, J. Roeleveld wrote:
> On Friday, December 21, 2012 12:42:23 PM Michał Górny wrote:
> > On Fri, 21 Dec 2012 12:31:28 +0100
> > 
> > "J. Roeleveld" <joost@antarean.org> wrote:
> > > On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
> > > > On Fri, 21 Dec 2012 11:24:45 +0100
> > > > 
> > > > "J. Roeleveld" <joost@antarean.org> wrote:
> > > > > On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
> > > > > > Just let me know when you have to maintain a lot of such systemd
> > > > > > and upgrade, say, glibc. Then maybe you'll understand.
> > > > > 
> > > > > A shared /usr means I need to update ALL the systems at once.
> > > > > When /usr is not shared, I can update groups at a time.
> > > > 
> > > > Yes, and this is what disqualifies it for the general case. If you
> > > > can't update one at some point, you can't update the others or it is
> > > > going to likely get broken in a random manner.
> > > 
> > > Yes, but do you want to find out when the entire production environment is
> > > down? Or would you rather do the upgrades in steps and only risk having to
> > > rebuild a few nodes and have a lower performance during that time?
> > > There is a big difference between 50% performance and 0%.
> > 
> > Didn't you just state that you *have* to update all at the same time?
> 
> Please re-read what I wrote.
> I said, with a *shared* /usr, then yes, I do need to update the entire 
> environment at the same time.

That's not true.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[J. Roeleveld]

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

Stelian Ionescu <sionescu@cddr.org> wrote:

>On Fri, 2012-12-21 at 12:48 +0100, J. Roeleveld wrote:
>> On Friday, December 21, 2012 12:42:23 PM Michał Górny wrote:
>> > On Fri, 21 Dec 2012 12:31:28 +0100
>> > 
>> > "J. Roeleveld" <joost@antarean.org> wrote:
>> > > On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
>> > > > On Fri, 21 Dec 2012 11:24:45 +0100
>> > > > 
>> > > > "J. Roeleveld" <joost@antarean.org> wrote:
>> > > > > On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
>> > > > > > Just let me know when you have to maintain a lot of such
>systemd
>> > > > > > and upgrade, say, glibc. Then maybe you'll understand.
>> > > > > 
>> > > > > A shared /usr means I need to update ALL the systems at once.
>> > > > > When /usr is not shared, I can update groups at a time.
>> > > > 
>> > > > Yes, and this is what disqualifies it for the general case. If
>you
>> > > > can't update one at some point, you can't update the others or
>it is
>> > > > going to likely get broken in a random manner.
>> > > 
>> > > Yes, but do you want to find out when the entire production
>environment is
>> > > down? Or would you rather do the upgrades in steps and only risk
>having to
>> > > rebuild a few nodes and have a lower performance during that
>time?
>> > > There is a big difference between 50% performance and 0%.
>> > 
>> > Didn't you just state that you *have* to update all at the same
>time?
>> 
>> Please re-read what I wrote.
>> I said, with a *shared* /usr, then yes, I do need to update the
>entire 
>> environment at the same time.
>
>That's not true.
>
>-- 
>Stelian Ionescu a.k.a. fe[nl]ix
>Quidquid latine dictum sit, altum videtur.
>http://common-lisp.net/project/iolib

How would you update a subset of servers when they all share the same /usr?

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

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

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

[William Hubbs]

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

On Fri, Dec 21, 2012 at 04:04:31PM +0100, J. Roeleveld wrote:
> On Friday, December 21, 2012 09:38:36 AM Rich Freeman wrote:
> > On Fri, Dec 21, 2012 at 8:51 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> > > On 21/12/12 03:10 AM, J. Roeleveld wrote:
> > >> An init* needs to be kept in sync with the rest of the system as
> > >> well.
> > > 
> > > Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
> > 
> > Seems likely.
> > 
> > However, for the most part it really only needs to be kept in sync
> > with the kernel.  Smarter ones like dracut that might do things like
> > keep a copy of mdadm.conf internally might need to be updated when
> > your disks change, and so on.  In general, however, they only need
> > changes when either your kernel changes, or the path to the root
> > filesystem changes (by path I mean mdadm/lvm/nfs/etc).
> 
> And with the "move to /usr", also when that changes.
> Granted, on most systems it won't actually move often once it's installed.

Can you be more specific here? I do not understand what you mean.

On the subject of generating an initramfs, you can build one if you
want, or there are tools in our tree that can build one for you. You
would use genkernel after a more current version is stabilized [1] or
dracut. This is covered in the initramfs guide [2].

Thanks,

William

[1] https://bugs.gentoo.org/441004
[2] http://www.gentoo.org/doc/en/initramfs-guide.xml

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[J. Roeleveld]

On Friday, December 21, 2012 10:21:02 AM William Hubbs wrote:
> On Fri, Dec 21, 2012 at 04:04:31PM +0100, J. Roeleveld wrote:
> > On Friday, December 21, 2012 09:38:36 AM Rich Freeman wrote:
> > > On Fri, Dec 21, 2012 at 8:51 AM, Ian Stakenvicius <axs@gentoo.org> 
wrote:
> > > > On 21/12/12 03:10 AM, J. Roeleveld wrote:
> > > >> An init* needs to be kept in sync with the rest of the system as
> > > >> well.
> > > > 
> > > > Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
> > > 
> > > Seems likely.
> > > 
> > > However, for the most part it really only needs to be kept in sync
> > > with the kernel.  Smarter ones like dracut that might do things like
> > > keep a copy of mdadm.conf internally might need to be updated when
> > > your disks change, and so on.  In general, however, they only need
> > > changes when either your kernel changes, or the path to the root
> > > filesystem changes (by path I mean mdadm/lvm/nfs/etc).
> > 
> > And with the "move to /usr", also when that changes.
> > Granted, on most systems it won't actually move often once it's installed.
> 
> Can you be more specific here? I do not understand what you mean.

The "path to /usr" won't change very often.

> On the subject of generating an initramfs, you can build one if you
> want, or there are tools in our tree that can build one for you. You
> would use genkernel after a more current version is stabilized [1] or
> dracut. This is covered in the initramfs guide [2].

As stated, I already tried genkernel and the current stable version actually 
does render a bootable version.
However, it is, in my opinion, a workaround for a problem that has been forced 
upon me. As soon as eudev is stable enough, I will dump udev.

> [1] https://bugs.gentoo.org/441004

Strange, I use a current-stable version of genkernel, /usr is on LVM and the 
system boots correctly without issues.

--
Joost

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

[Dale]

J. Roeleveld wrote:
> However, it is, in my opinion, a workaround for a problem that has
> been forced upon me. As soon as eudev is stable enough, I will dump udev.
>> [1] https://bugs.gentoo.org/441004
> Strange, I use a current-stable version of genkernel, /usr is on LVM and the 
> system boots correctly without issues.
>
> --
> Joost
>
>

Same here.  I have /usr on LVM and plan to use eudev as SOON as it is
ready.  I'm just waiting on someone to post that it is as easy as
unmerging udev and emerging eudev and maybe a reboot. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

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

[J. Roeleveld]

Dale <rdalek1967@gmail.com> wrote:

>J. Roeleveld wrote:
>> However, it is, in my opinion, a workaround for a problem that has
>> been forced upon me. As soon as eudev is stable enough, I will dump
>udev.
>>> [1] https://bugs.gentoo.org/441004
>> Strange, I use a current-stable version of genkernel, /usr is on LVM
>and the 
>> system boots correctly without issues.
>>
>> --
>> Joost
>>
>>
>
>Same here.  I have /usr on LVM and plan to use eudev as SOON as it is
>ready.  I'm just waiting on someone to post that it is as easy as
>unmerging udev and emerging eudev and maybe a reboot. 
>
>Dale
>
>:-)  :-) 

As soon as the developers post it is ready for testing I will start testing it on a few test VMs. If that works I will move it to my desktop.
When that also goes fine. I'll post about it on gentoo-user.

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/12/12 01:05 PM, J. Roeleveld wrote:
> Dale <rdalek1967@gmail.com> wrote:
> 
>> J. Roeleveld wrote:
>>> However, it is, in my opinion, a workaround for a problem that
>>> has been forced upon me. As soon as eudev is stable enough, I
>>> will dump
>> udev.
>>>> [1] https://bugs.gentoo.org/441004
>>> Strange, I use a current-stable version of genkernel, /usr is
>>> on LVM
>> and the
>>> system boots correctly without issues.
>>> 
>>> -- Joost
>>> 
>>> 
>> 
>> Same here.  I have /usr on LVM and plan to use eudev as SOON as
>> it is ready.  I'm just waiting on someone to post that it is as
>> easy as unmerging udev and emerging eudev and maybe a reboot.
>> 
>> Dale
>> 
>> :-)  :-)
> 
> As soon as the developers post it is ready for testing I will start
> testing it on a few test VMs. If that works I will move it to my
> desktop. When that also goes fine. I'll post about it on
> gentoo-user.
> 
> -- Joost

Since this thread has actually gone back to being about eudev, I'll
chime in here:

I haven't tested this against separate-/usr but from my look at how
~arch lvm2 builds, it will -not- work against eudev-1_beta1 or
eudev-9999 as it stands today in a separate-/usr environment.

We will of course support this but support is not there yet.  IMO it's
not worth attempting at this point as it will most likely fail.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDUpzgACgkQ2ugaI38ACPCZcwEAnwGAIK5+MjesTb5Eaw03Hr+m
rgHVu8QQrAbLFyyUU7ABALby/1B+nwTct4Uze07V+//gX4ZRUw83+RzhwIQw/Mfh
=ZgO4
-----END PGP SIGNATURE-----

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

[William Hubbs]

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

On Fri, Dec 21, 2012 at 06:36:05PM +0100, J. Roeleveld wrote:
> On Friday, December 21, 2012 10:21:02 AM William Hubbs wrote:
> > On Fri, Dec 21, 2012 at 04:04:31PM +0100, J. Roeleveld wrote:
> > > On Friday, December 21, 2012 09:38:36 AM Rich Freeman wrote:
> > > > On Fri, Dec 21, 2012 at 8:51 AM, Ian Stakenvicius <axs@gentoo.org> 
> wrote:
> > > > > On 21/12/12 03:10 AM, J. Roeleveld wrote:
> > > > >> An init* needs to be kept in sync with the rest of the system as
> > > > >> well.
> > > > > 
> > > > > Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
> > > > 
> > > > Seems likely.
> > > > 
> > > > However, for the most part it really only needs to be kept in sync
> > > > with the kernel.  Smarter ones like dracut that might do things like
> > > > keep a copy of mdadm.conf internally might need to be updated when
> > > > your disks change, and so on.  In general, however, they only need
> > > > changes when either your kernel changes, or the path to the root
> > > > filesystem changes (by path I mean mdadm/lvm/nfs/etc).
> > > 
> > > And with the "move to /usr", also when that changes.
> > > Granted, on most systems it won't actually move often once it's installed.
> > 
> > Can you be more specific here? I do not understand what you mean.

The /usr merge doesn't break an init*, so I don't know how you are seeing
them as related.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[J. Roeleveld]

On Friday, December 21, 2012 12:20:45 PM William Hubbs wrote:
> On Fri, Dec 21, 2012 at 06:36:05PM +0100, J. Roeleveld wrote:
> > On Friday, December 21, 2012 10:21:02 AM William Hubbs wrote:
> > > On Fri, Dec 21, 2012 at 04:04:31PM +0100, J. Roeleveld wrote:
> > > > On Friday, December 21, 2012 09:38:36 AM Rich Freeman wrote:
> > > > > On Fri, Dec 21, 2012 at 8:51 AM, Ian Stakenvicius <axs@gentoo.org>
> > 
> > wrote:
> > > > > > On 21/12/12 03:10 AM, J. Roeleveld wrote:
> > > > > >> An init* needs to be kept in sync with the rest of the system as
> > > > > >> well.
> > > > > > 
> > > > > > Just to be clear, by "init*" you mean {initrd,initramfs} ,
> > > > > > correct?
> > > > > 
> > > > > Seems likely.
> > > > > 
> > > > > However, for the most part it really only needs to be kept in sync
> > > > > with the kernel.  Smarter ones like dracut that might do things like
> > > > > keep a copy of mdadm.conf internally might need to be updated when
> > > > > your disks change, and so on.  In general, however, they only need
> > > > > changes when either your kernel changes, or the path to the root
> > > > > filesystem changes (by path I mean mdadm/lvm/nfs/etc).
> > > > 
> > > > And with the "move to /usr", also when that changes.
> > > > Granted, on most systems it won't actually move often once it's
> > > > installed.
> > > 
> > > Can you be more specific here? I do not understand what you mean.
> 
> The /usr merge doesn't break an init*, so I don't know how you are seeing
> them as related.

Who are you replying to here?
I never said that moving everything into /usr will break an init*.

--
Joost