[gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Fabian Groffen]

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

In two weeks from now, the council will meet again.  This is the time
to raise and prepare items that the council should put on the agenda to         
vote on.

Please respond to this email with agenda items.  Please do not hestitate
to repeat your agenda item here with a pointer if you previously
suggested one (since the last meeting).

The agenda for the next meeting will be sent out by the meeting's
chairman on Tuesday 1st of May 2012.

Please respond to gentoo-project list, if possible.        

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Ulrich Mueller]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1165 bytes --]

>>>>> On Tue, 24 Apr 2012, Fabian Groffen wrote:

> In two weeks from now, the council will meet again. This is the time
> to raise and prepare items that the council should put on the agenda
> to vote on.

I would like the council to vote on the following two topics:

1. Following up to last month's topic "EAPI specification in ebuilds",
   the exact specification for PMS has been discussed in the
   gentoo-pms mailing list. See the full thread in [1], and the final
   wording in [2]. (For convenience, it is also attached to this
   message as plain text and as git-formatted patch.)

2. Related to this: GLEP 55 is still tagged as "Draft" [3].
   Considering previous council decisions [4,5] on the subject,
   I suggest that its status is changed to "Rejected".

Ulrich

[1] <http://archives.gentoo.org/gentoo-pms/msg_ef7635aa655913f2386e64e385f5a6ae.xml>
[2] <http://archives.gentoo.org/gentoo-pms/msg_3a441be5e49cc06689ecab00da461278.xml>
[3] <http://www.gentoo.org/proj/en/glep/#doc_chap4_sect3>
[4] <http://www.gentoo.org/proj/en/council/meeting-logs/20100823-summary.txt>
[5] <http://www.gentoo.org/proj/en/council/meeting-logs/20120403-summary.txt>


[-- Attachment #2: 0001-Specify-syntax-of-EAPI-assignment-for-parsing-by-pac.patch --]
[-- Type: text/plain, Size: 2974 bytes --]

If the EAPI is to be specified in an ebuild, the EAPI variable must
be assigned to precisely once. The assignment must not be preceded
by any lines other than blank lines or those that start with optional
whitespace (spaces or tabs) followed by a # character, and the line
containing the assignment statement must match the following regular
expression:
^[ \t]*EAPI=(['"]?)([A-Za-z0-9+_.-]*)\1[ \t]*(#.*)?$

The package manager may optionally determine the EAPI of an ebuild
by parsing its first non-blank and non-comment line, using above
regular expression. If a recognised EAPI has been determined such,
then the package manager must make sure that the EAPI value obtained
by sourcing the ebuild with bash is identical to the EAPI obtained
by parsing. The ebuild must be treated as invalid if these values are
different.


From c52a11a8e28eb81c6f40e0edcfea65c68bcb2a82 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Sun, 15 Apr 2012 12:15:46 +0200
Subject: [PATCH] Specify syntax of EAPI assignment for parsing by package
 managers.

---
 ebuild-vars.tex |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/ebuild-vars.tex b/ebuild-vars.tex
index d971234..f3b72bf 100644
--- a/ebuild-vars.tex
+++ b/ebuild-vars.tex
@@ -75,7 +75,7 @@ Ebuilds may define any of the following variables:
 
 \begin{description}
 \item[DEPEND] See section~\ref{sec:dependencies}.
-\item[EAPI] The EAPI. See below for defaults.
+\item[EAPI] The EAPI. See below.
 \item[PDEPEND] See section~\ref{sec:dependencies}.
 \item[RDEPEND] See section~\ref{sec:dependencies}. For some EAPIs, \t{RDEPEND} has special behaviour
     for its value if unset and when used with an eclass. See section~\ref{sec:rdepend-depend} for
@@ -124,6 +124,20 @@ ensure that it is unset.
 If any of these variables are set to invalid values, the package manager's behaviour is undefined;
 ideally, an error in one ebuild should not prevent operations upon other ebuilds or packages.
 
+If the EAPI is to be specified in an ebuild, the \t{EAPI} variable must be assigned to precisely
+once. The assignment must not be preceded by any lines other than blank lines or those that start
+with optional whitespace (spaces or tabs) followed by a \t{\#} character, and the line containing
+the assignment statement must match the following regular expression:
+\begin{verbatim}
+^[ \t]*EAPI=(['"]?)([A-Za-z0-9+_.-]*)\1[ \t]*(#.*)?$
+\end{verbatim}
+
+The package manager may optionally determine the EAPI of an ebuild by parsing its first non-blank
+and non-comment line, using above regular expression. If a recognised EAPI has been determined
+such, then the package manager must make sure that the \t{EAPI} value obtained by sourcing the
+ebuild with bash is identical to the EAPI obtained by parsing. The ebuild must be treated as
+invalid if these values are different.
+
 \subsection{\t{RDEPEND} value}
 \label{sec:rdepend-depend}
 
-- 
1.7.8.5

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[William Hubbs]

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

On Tue, Apr 24, 2012 at 08:21:41PM +0200, Fabian Groffen wrote:
> In two weeks from now, the council will meet again.  This is the time
> to raise and prepare items that the council should put on the agenda to         
> vote on.
> 
> Please respond to this email with agenda items.  Please do not hestitate
> to repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).

Council members,

I am very concerned about your vote last meeting with regard to separate
/usr being supported. Whether or not it will be supported is not a valid
question, because it will be.

There is now division in the community about your vote, so I am formally
requesting a clarification.

I can assure the council that we are not going to try to stabilize newer
versions of udev out of hand. We have a tracker bug open which will show
all of the tasks we need to complete before that happens [1].

Once that happens, I want to start looking into the /usr merge (see
below).

I think the more appropriate question is, do we want to continue
attempting to support /usr as a separate partition without an initramfs?

This affects much more than udev. There is another event happening in
the linux community which is referred to as the /usr merge [2]. I know
this is happening on Fedora. I believe archlinux is looking into doing
this, and Debian is as well.

One advantage gentoo, as a distro, would have if we do the /usr merge is
that we can get rid of gen_usr_ldscript. This was put in place as a
workaround [3], and we would be able to remove it.

Any distribution which does the /usr merge will not be able to support /usr
as a separate partition without an initramfs, and I think it is just a
matter of time until packages don't check /{sbin,bin,lib*} any longer.

We did have a pretty extensive discussion on the dev mailing list
regarding the /usr merge, and my feeling from the community was that we
should do this [4].

In summary, I feel that if we continue supporting separate /usr without
an initramfs, we will be harming our distro in the long run, so I would
ask you to please carefully consider this before you vote.

Thanks much,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=411627
[2] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
[3] https://bugs.gentoo.org/show_bug.cgi?id=4411
[4] http://archives.gentoo.org/gentoo-dev/msg_c3c5bdabbe058b08627ff04cee896af3.xml

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

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/24/2012 08:56 PM, William Hubbs wrote:
> On Tue, Apr 24, 2012 at 08:21:41PM +0200, Fabian Groffen wrote:
>> In two weeks from now, the council will meet again.  This is the
>> time to raise and prepare items that the council should put on
>> the agenda to vote on.
>> 
>> Please respond to this email with agenda items.  Please do not
>> hestitate to repeat your agenda item here with a pointer if you
>> previously suggested one (since the last meeting).
> 
> Council members,
> 
> I am very concerned about your vote last meeting with regard to
> separate /usr being supported. Whether or not it will be supported
> is not a valid question, because it will be.
> 
> There is now division in the community about your vote, so I am
> formally requesting a clarification.
> 
> I can assure the council that we are not going to try to stabilize
> newer versions of udev out of hand. We have a tracker bug open
> which will show all of the tasks we need to complete before that
> happens [1].
> 
> Once that happens, I want to start looking into the /usr merge
> (see below).
> 
> I think the more appropriate question is, do we want to continue 
> attempting to support /usr as a separate partition without an
> initramfs?
> 
> This affects much more than udev. There is another event happening
> in the linux community which is referred to as the /usr merge [2].
> I know this is happening on Fedora. I believe archlinux is looking
> into doing this, and Debian is as well.
> 
> One advantage gentoo, as a distro, would have if we do the /usr
> merge is that we can get rid of gen_usr_ldscript. This was put in
> place as a workaround [3], and we would be able to remove it.
> 
> Any distribution which does the /usr merge will not be able to
> support /usr as a separate partition without an initramfs, and I
> think it is just a matter of time until packages don't check
> /{sbin,bin,lib*} any longer.
> 
> We did have a pretty extensive discussion on the dev mailing list 
> regarding the /usr merge, and my feeling from the community was
> that we should do this [4].
> 
> In summary, I feel that if we continue supporting separate /usr
> without an initramfs, we will be harming our distro in the long
> run, so I would ask you to please carefully consider this before
> you vote.
> 
> Thanks much,
> 
> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=411627 [2]
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
>
> 
[3] https://bugs.gentoo.org/show_bug.cgi?id=4411
> [4]
> http://archives.gentoo.org/gentoo-dev/msg_c3c5bdabbe058b08627ff04cee896af3.xml

I
> 
was very confused the first time this topic was brought to the
Council. I still believe this is not something we (Council) should
decide but rather the udev maintainers should decide themselves. In
any case, I am fine with bringing this issue back to Council as it
seems there is a general confusion in the Gentoo community about this.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPlyEtAAoJEPqDWhW0r/LCcP4P/idWNSK4M3AOBmKgmr9E4xDe
kxRBzSF4Xj+crohpYVT+dd9JAxfTlxPqwG0HyxktvGccZPMbMqweNEh6tb6Y1j7W
VtcmBxY5DZntr1qZAu4agr9SkHufl6E2ptxK/+YMkXqgc9fUOIvWaeolqTQmPh62
zt43zgsDQqNiMksR+kV2iBXuHEmVpGpJ7iUAbiq+Mh5ifXbRJodXy4ELQP71y1fu
UKu1Pp8AY0fuV43wfdHBR9BzyQvL1d7H+HfvwDVej4bDuWftEfWVGoXnHGJSv6gA
I4CEF29nn3gbw++/gv7AdCf6DWxkFXCn8JqUOQhhX4mre/mKrMsffKIibZImKa6p
hE6k4PxY6VqdTMfMUqSqMh8NufR7cuQL1yG8CZEDJmz/ruCwRT66u66Sb7CzVxA/
mzXVQXCKCfCaa3klliMY9yFBtbKs7YAXBzmky3HFzs3UBwyTadbmvqw0UeTdXaHp
/EiYg2rElvK4BX4eEgBYa+40Q0nDAzC6IMAIftvHlvwb6t/dk8rHdmGtFX6689P8
AWoVsU1ooL3Gf6yOyNb5GE6zsDAMzbFa60gr5g10LmxD7n4FFzjwsKGZhrCtG0ek
M8I/eAXCB4uQ/+tJTYPwb6boyv5giB7bWPMhBvcAAoTuEIzx1OPIE6UKGNdytxTj
cBlWOphMavH3+h7HOoYJ
=mOHn
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[William Hubbs]

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

On Tue, Apr 24, 2012 at 10:54:53PM +0100, Markos Chandras wrote:
> I
> was very confused the first time this topic was brought to the
> Council. I still believe this is not something we (Council) should
> decide but rather the udev maintainers should decide themselves. In
> any case, I am fine with bringing this issue back to Council as it
> seems there is a general confusion in the Gentoo community about this.

Honestly, I agree with you. I am a udev maintainer myself, and the udev
maintainers did not bring this issue to council. More than that, no one,
that I recall, discussed any ramifications of this vote with any udev
maintainers before bringing it to council.

The ramifications, as I said in my previous email, are not just udev
related (see the section in my previous email about the /usr merge).

Once we start implementing the /usr merge, it will not matter whether
you use udev or not,  you will have to have an initramfs if your /usr is
separate.

William


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

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Rich Freeman]

On Tue, Apr 24, 2012 at 6:26 PM, William Hubbs <williamh@gentoo.org> wrote:
> Honestly, I agree with you. I am a udev maintainer myself, and the udev
> maintainers did not bring this issue to council. More than that, no one,
> that I recall, discussed any ramifications of this vote with any udev
> maintainers before bringing it to council.
>
> The ramifications, as I said in my previous email, are not just udev
> related (see the section in my previous email about the /usr merge).
>
> Once we start implementing the /usr merge, it will not matter whether
> you use udev or not,  you will have to have an initramfs if your /usr is
> separate.

I have mixed feelings on this.

The fact that the ramifications are not just udev-related tends to
point to the fact that this shouldn't simply be up to the udev team.
These are big changes for Gentoo, and there is a great deal of
controversy across the Linux world resulting from them (the
Shuttleworth vs Pottering debate being the latest iteration of this).
Everybody has to live with this stuff, which points to council
involvement.

On the other hand, somebody has to maintain all this code, so having a
bunch of non-udev-maintainers telling them what to do is not a great
thing either.  Worst case you end up with a bunch of frustrated people
giving up on it, which leaves us much worse off.  If you are paying
your staff you can tell them what to do, but with volunteers you need
to be more "inspirational" in your leadership.  If the udev team
thinks this is the way the wind is blowing then either more people
need to step up and help them maintain more configurability, or we
need to just work with them to make the ride as smooth as we can.  I
don't think anybody wants to see needless end-user pain here in any
case, and as far as I can tell the udev maintainers are quite willing
to work with other projects (genkernel, dracut, docs, etc) as needed.

Lots of people have pointed out alternative options, and I've always
been a proponent of "Gentoo is about choice."  However, if we want a
choice to be available people do need to step up and make those
choices available.  Volunteer distros don't work well when people tell
others how to maintain their code.  We struggle enough with basic
quality control sometimes, and I think most of us can admit it when we
make a mistake in these areas (if for no reason than out of pride in
our work).  To ask developers to build to somebody else's design in a
volunteer organization may be asking a bit much.

I think the best we can do is look for opportunities to give people
choices when they're practical, and when people are willing to pitch
in and maintain their side of the interfaces.  You don't even have to
be a Gentoo developer to do that - just look at OpenRC/etc - get an
account on github, do good work, and ask some developer to commit your
ebuilds.

Rich

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[William Hubbs]

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

On Tue, Apr 24, 2012 at 08:20:10PM -0400, Rich Freeman wrote:
> The fact that the ramifications are not just udev-related tends to
> point to the fact that this shouldn't simply be up to the udev team.
> These are big changes for Gentoo, and there is a great deal of
> controversy across the Linux world resulting from them (the
> Shuttleworth vs Pottering debate being the latest iteration of this).
> Everybody has to live with this stuff, which points to council
> involvement.

Everybody has to live with this stuff couldn't be more true. We are
talking about changes in the linux world that are coming from outside of
gentoo.

> On the other hand, somebody has to maintain all this code, so having a
> bunch of non-udev-maintainers telling them what to do is not a great
> thing either.  Worst case you end up with a bunch of frustrated people
> giving up on it, which leaves us much worse off.  If you are paying
> your staff you can tell them what to do, but with volunteers you need
> to be more "inspirational" in your leadership.  If the udev team
> thinks this is the way the wind is blowing then either more people
> need to step up and help them maintain more configurability, or we
> need to just work with them to make the ride as smooth as we can.  I
> don't think anybody wants to see needless end-user pain here in any
> case, and as far as I can tell the udev maintainers are quite willing
> to work with other projects (genkernel, dracut, docs, etc) as needed.

Like I said above, it isn't just the udev maintainers. We aren't talking
about changes to udev. we are talking about changes to the entire
linux ecosystem.

> I think the best we can do is look for opportunities to give people
> choices when they're practical, and when people are willing to pitch
> in and maintain their side of the interfaces.  You don't even have to
> be a Gentoo developer to do that - just look at OpenRC/etc - get an
> account on github, do good work, and ask some developer to commit your
> ebuilds.

I too am definitely a proponent of choice. However, I don't feel that
the choice of having /usr on a separate file system without using an
initramfs is a practical one to offer; especially with the /usr merge
coming down the pipe.

I didn't like making the change either. But, after some thought and
reading the arguments supporting it, I did, because I can see how it
will make things easier in the future.

Building an initramfs that works was simple on my system using genkernel; the
tracker for udev points to the bug that shows how to do it.

Once the documentation for setting up an initramfs is in place which
will be done before >=udev-182 is stabilized, all you will need to do is
set one up, then you can just enjoy the ride. We will not start the /usr
merge before this udev is stabilized.

William


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

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Roy Bamford]

On 2012.04.25 01:20, Rich Freeman wrote:
> On Tue, Apr 24, 2012 at 6:26 PM, William Hubbs <williamh@gentoo.org>
> wrote:
> > Honestly, I agree with you. I am a udev maintainer myself, and the
> udev
> > maintainers did not bring this issue to council. More than that, no
> one,
> > that I recall, discussed any ramifications of this vote with any
> udev
> > maintainers before bringing it to council.
> >
> > The ramifications, as I said in my previous email, are not just 
> udev
> > related (see the section in my previous email about the /usr 
> merge).
> >
> > Once we start implementing the /usr merge, it will not matter
> whether
> > you use udev or not,  you will have to have an initramfs if your
> /usr is
> > separate.
> 
> I have mixed feelings on this.
> 
> The fact that the ramifications are not just udev-related tends to
> point to the fact that this shouldn't simply be up to the udev team.
> These are big changes for Gentoo, and there is a great deal of
> controversy across the Linux world resulting from them (the
> Shuttleworth vs Pottering debate being the latest iteration of this).
> Everybody has to live with this stuff, which points to council
> involvement.
> 
[snip]
> Rich
> 

Council involvement is only useful where there is a choice to be made
between alternatives and the proponents of the options can't agree.
In the udev case, there is as yet, no viable alternative, so the option 
is take it or leave it.

Gentoo may wish to support separate /usr without an initrd but until 
the code base allows it, there is nothing for the council to vote on. 
-- 
Regards,

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

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Roy Bamford]

On 2012.04.24 19:21, Fabian Groffen wrote:
> In two weeks from now, the council will meet again.  This is the time
> to raise and prepare items that the council should put on the agenda
> to         
> vote on.
> 
> Please respond to this email with agenda items.  Please do not
> hestitate
> to repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).
> 
> The agenda for the next meeting will be sent out by the meeting's
> chairman on Tuesday 1st of May 2012.
> 
> Please respond to gentoo-project list, if possible.        
> 
> -- 
> Fabian Groffen
> Gentoo on a different level
> 

The May meeting should be the penultimate meeting of the present 
council. Individual council members should spend a few minutes each 
summing up their achievements over their term of office.  What went 
right, what went wrong, lessons learned, do they intend to stand for 
reelection during June etc?

There is nothing for the council to vote on here - the electorate will 
do that later.

-- 
Regards,

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

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Dale]

Roy Bamford wrote:

> Council involvement is only useful where there is a choice to be made
> between alternatives and the proponents of the options can't agree.
> In the udev case, there is as yet, no viable alternative, so the option 
> is take it or leave it.
> 
> Gentoo may wish to support separate /usr without an initrd but until 
> the code base allows it, there is nothing for the council to vote on. 


What did they vote on during the last meeting then?

Just curious.

Dale

:-)  :-)

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

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Fabian Groffen]

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

On 24-04-2012 22:34:45 -0500, William Hubbs wrote:
> Everybody has to live with this stuff couldn't be more true. We are
> talking about changes in the linux world that are coming from outside of
> gentoo.

[snip]

> Like I said above, it isn't just the udev maintainers. We aren't talking
> about changes to udev. we are talking about changes to the entire
> linux ecosystem.

[snip]

> I too am definitely a proponent of choice. However, I don't feel that
> the choice of having /usr on a separate file system without using an
> initramfs is a practical one to offer; especially with the /usr merge
> coming down the pipe.


The great /usr merge.

As far as I have understood from previous discussions here, the GnomeOS
folks have a vision that constitutes a one thing to rule them all
approach.  It makes their life (from a binary point of view) easier.

- If we want to follow the current trend in desktop systems, we need to
  follow the GnomeOS vision.
- The GnomeOS vision dictates that a vast majority of modules, libraries
  and programs are available early during boot.  They have chosen to
  expect them to be in /usr, and hence that /usr is availble early
  during boot.

In the past, and it is suggested in the quoted email again, it was
claimed that everyone will start installing stuff in /usr, because of
the GnomeOS vision.  The only proof being brought up back then actually
turned out not to be supporting that claim.

It was claimed multiple times that recent Solaris would have done "the
/usr merge" as well, but to my best understanding, this was based on a
misunderstanding of historical Solaris characteristics.  IMO UNIX
mandates "the /usr merge" not to happen.

Clearly, there is a drive to comply to the GnomeOS vision.  With the
characteristics and tools of Gentoo, this seems to be easy to
effectuate.  However, people that do not want to go with the GnomeOS
vision, are affected by just moving tools to /usr.  This is my
understanding of where problems arise, and why the council was involved.

People that do not want to follow the path of the GnomeOS vision, need
to stay with "old" software.  Software that we developed ourselves, or
that we've been using for a long time to get the systems working as we
want.  Because of the drive of current maintainers of critical software
components to follow the GnomeOS vision, the council has found people
willing to keep the current state of software running.  This means, that
those people who want to move on, following the vision they believe in,
can do so, without being forced to do things they don't believe in.

In my humble opinion, the essential bit missing here, is where both
camps respect each other.  That is, not to make it impossible for either
camp to follow their vision.
I've made suggestions for this in the last council meeting.  The options
we have as Gentoo -- a remarkable flexible and well controllable
source-based distribution -- are numerous.  We can have special
profiles, introduce new USE-flags, etc.

So far, the discussion has indicated not more than a shift of programs
from / to /usr.  This, IMO, should be controlled by a profile/use-flag
setting.  That is, gen_usr_ldscript should NOT go, but rather stay, and
just do nothing if the user is following the GnomeOS vision.

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[Zac Medico]

On 04/27/2012 12:13 AM, Fabian Groffen wrote:
> In my humble opinion, the essential bit missing here, is where both
> camps respect each other.  That is, not to make it impossible for either
> camp to follow their vision.
> I've made suggestions for this in the last council meeting.  The options
> we have as Gentoo -- a remarkable flexible and well controllable
> source-based distribution -- are numerous.  We can have special
> profiles, introduce new USE-flags, etc.
> 
> So far, the discussion has indicated not more than a shift of programs
> from / to /usr.  This, IMO, should be controlled by a profile/use-flag
> setting.  That is, gen_usr_ldscript should NOT go, but rather stay, and
> just do nothing if the user is following the GnomeOS vision.

Has anybody created an antithetical document to "The Case for the /usr
Merge"? It could be called "The Case Against the /usr Merge", and it
would be useful to have such a document in order to justify support of
the special profiles and USE-flags that you propose.

There is an obvious demand to provide a way forward for Gentoo's
installed base of separate-/usr-without-initramfs systems, but using
your proposed profiles and USE-flags as the way forward seems like
overkill in comparison to the simple alternatives that exist:

  Alternative 1: Don't install /usr on a separate partition
  Alternative 2: Mount /usr early with an initramfs

So, if we're going to move forward with your proposed profiles and
USE-flags, then let's create a document to justify it.
-- 
Thanks,
Zac

Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08

[William Hubbs]

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

 First off, we are not talking about Gnome OS. I personally am not a
 gnome user; I have know idea how to use it.

Also, I have /usr on a separate partition. I was against this change
initially, but after thinking about it, it makes a lot of sense.

This is the first issue we are talking about [1], and if you read it over,
you will see that gnome isn't driving this.

Regarding the case for the /usr merge, it again has nothing to do with
gnome. It is a simplification of the filesystem layout which
offers some compelling advantages [2].

As someone else said in this
thread, I have never seen a "case against the /usr merge" explaining why
it shouldn't happen.

 William

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

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