[gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[Jorge Manuel B. S. Vicetto]

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

Hello fellow developers and community,

the next council meeting will be on Tuesday 8th May 2012 at 19:00 UTC
[1] in the #gentoo-council channel on Freenode.

Proposed agenda:

1. Introduction and roll call (5 minutes)

2. EAPI specification in ebuilds [2] (20 minutes)

   1. Vote on final PMS wording [3] (discussion [4])
   2. Vote to change the status of GLEP55 [5]

3. Separate /usr partition vote of last meeting (20 minutes)

   Following the vote about Gentoo supporting separate /usr
   installations in the last meeting, the mls became active
   about the meaning and consequences of such vote.
   William made a direct request to the council to review the
   vote [6].

4. Review of the council term (10 minutes)

   Roy suggested [7] the council members do a review of their
   mandate in the last meeting before the election.

5. Open floor


 [1] - http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900
 [2] -
http://archives.gentoo.org/gentoo-project/msg_e6eafd6be25794ca503e0ac9d6968cd3.xml
 [3] -
http://archives.gentoo.org/gentoo-pms/msg_3a441be5e49cc06689ecab00da461278.xml
 [4] -
http://archives.gentoo.org/gentoo-pms/msg_ef7635aa655913f2386e64e385f5a6ae.xml
 [5] - http://www.gentoo.org/proj/en/glep/glep-0055.html
 [6] -
http://archives.gentoo.org/gentoo-project/msg_5a3e7a62abc3f6f529cbb18d85f2fbcf.xml
 [7] -
http://archives.gentoo.org/gentoo-project/msg_0e09e374488d2393c6cf794e349dc614.xml

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPoJXOAAoJEC8ZTXQF1qEPDmQP/RwgLkq1VSOtGK/bE1jA8Gqq
Q0CYsNuO5wGNUb5faauNcobuJNqTmrruv4ChoXRs+zKMnBRztILVzPkUqG3m0KXN
+w6w8Hgi48L6MZBhpq9pj73ePYbWGIe9EWs1BOTM72T9t7pp9op4lAGhfLLsD4vH
KQdBU5WOfO2zMz8kU2aM9NkZb2JfnUprxyIsPrZ0JnLw4HMt8WY9jVkvyx9htbYI
k+DrHyV6M6suFW7SVEukCdxcmW/4LUBf29Ue8d9ZSIL/aWQvH4UjqzoER1BWKoHK
xzU3Oqx2+77piwaXuONjiSDxJNW4Qcwrhn0kvDc3pkA4IC2fTt2P0BJXFDH0kXka
ZGbBFjGdgpj1MkyPOg6LydywSaXNIoaZbw5GxzpnxGTexJ5uwGBUvLswiH6hVThe
+IQJQ8Ph7ynW/oRnfoQzSlstQNCr/vXrG5ix3+PZmS43vItHZa5uIsdjMZrHqTrx
yl6tTj/u2jNgBmDF3RKE7AK/huHa9WHDvKEVmoZRFjxNQ6HRUPHUV5hrmOb53dvZ
GV/17U9bUsonnDKGg9vzhfD+YfihDB2NzDKBEPd1kjzRzeRku9PzZlJLv3UANMti
ADHdsA5O5inXceR5CIzLHPnC/a5j8ym2a7OTIUFEI5JlVs+UsLZnon4LX4hCOZFl
BER2n1/IzSE/xp33i2LE
=TuSz
-----END PGP SIGNATURE-----

Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[William Hubbs]

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

On Wed, May 02, 2012 at 02:02:54AM +0000, Jorge Manuel B. S. Vicetto wrote:
> 3. Separate /usr partition vote of last meeting (20 minutes)

Hello Council Members,

I was told that responding here is the best way to add information to
the discussion you will have in the upcoming meeting about this vote, so
that is why I am replying to this thread.

Everyone seems to be focused on udev, but  this issue goes a bit further
than udev. I'm sure you have all read the document asserting why
separate /usr without an initramfs is broken, but I'm going to reference
it here just in case [1].

The following are concerns I have about us mandating that separate /usr
without an initramfs is how we are going to do things:

- We would have to introduce a new top-level directory, /share, as a
  counterpart to /usr/share. This would be for programs that currently
  read data from /usr/share but need to be made available in early boot.

- Anything we might use at all during early boot must be stored in /,
  along with all of its dependencies.

- Any program that hooks itself into udev must automatically be moved to
  / along with its dependencies.

- The locale logic in linux always looks for information in
  /usr/share/locale. We would need to patch gettext to look in
  /share/locale as well.

- If we decide a program needs to go into /, it, and all of its
  dependencies will need to be customized in the build process, and
  probably patched, to not refer to anything outside of /.

- / will not be able to be kept small, which is a concern of some of our
  users.

- Any patches we come up with to handle these issues most likely
  wouldn't be accepted into upstream, so we would be carrying them
  forever.

If you use an initramfs to pre-mount /usr, all of these issues are moot
and things just work (tm). Mike's sep-usr use flag option on busybox
may do this, but see below.

- Separate /usr without initramfs blocks the /usr merge.
  In my original request to have your vote reviewed, I pointed out the
  document which asserts that the /usr merge is a good thing and pointed
  out the thread in which we discussed it on -dev. The arguments
  supporting it are strong, and I haven't seen any technical argument
  against it that would not be addressed by using an initramfs with
  separate /usr. If you are using an initramfs, you will never know
  when the /usr merge happens, but if you are using something like
  Mike's option your system is not compatible with the merge.

I also want to point out something out of the meeting log:

<dberkholz> here's the thing
<dberkholz> who's going to either "port" udev as necessary, or maintain an old
version forever?					        [21:36]
		<dberkholz> we can't proclaim things like this from on high
		without a route
			    forward
				<Chainsaw> I will keep an old version going until the
				end of time.
				<hwoarang> if udev is moving that way, we can't stay
				'old' forever
				<dberkholz> what happens when kernel 3.6 no longer
				supports it?
				<Chainsaw> Then dev(tmp)fs will win.

The new udev requires devtmpfs to function. devtmpfs creates the device
nodes and udev manages everything else such as permissions, running
external programs for certain events, loading kernel modules and
creating extra symbolic links to device nodes. I do not see all of that
functionality being moved into devtmpfs. So IMO the question still
remains. If we take that route, what happens when the newer kernels do
not support the older version of udev any longer?

There is now a tracker bug open for the tasks which need to be done
before newer udevs can be stabilized [2], and the documentation team has
an initramfs guide [3].

My position is that we should use initramfs as our default method of
supporting separate /usr, because if we don't, we will be hurting
our distribution. We will require more and more things to be installed
in / which will not be able to be kept small, we will create extra work
for our maintainers who will have to maintain custom builds of their
packages to support this, and we will block ourselves from doing the
/usr merge.

Thanks for your time.

William

[1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
[2] http://bugs.gentoo.org/411627
[3] http://www.gentoo.org/doc/en/initramfs-guide.xml

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

Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1163 bytes --]

On Friday 04 May 2012 19:06:37 William Hubbs wrote:
> If you use an initramfs to pre-mount /usr, all of these issues are moot
> and things just work (tm). Mike's sep-usr use flag option on busybox
> may do this, but see below.
> 
> - Separate /usr without initramfs blocks the /usr merge.
>   In my original request to have your vote reviewed, I pointed out the
>   document which asserts that the /usr merge is a good thing and pointed
>   out the thread in which we discussed it on -dev. The arguments
>   supporting it are strong, and I haven't seen any technical argument
>   against it that would not be addressed by using an initramfs with
>   separate /usr. If you are using an initramfs, you will never know
>   when the /usr merge happens, but if you are using something like
>   Mike's option your system is not compatible with the merge.

why exactly do you say that ?  i already explained that busybox[sep-usr] works 
perfectly fine in a /usr-merged world.  the /ginit static ELF literally needs 
nothing else in the system to work.  you could boot a rootfs where the only 
thing in / was ginit and it wouldn't be a problem.
-mike

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

Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[William Hubbs]

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

On Fri, May 04, 2012 at 08:46:21PM -0400, Mike Frysinger wrote:
> On Friday 04 May 2012 19:06:37 William Hubbs wrote:
> > If you use an initramfs to pre-mount /usr, all of these issues are moot
> > and things just work (tm). Mike's sep-usr use flag option on busybox
> > may do this, but see below.
> > 
> > - Separate /usr without initramfs blocks the /usr merge.
> >   In my original request to have your vote reviewed, I pointed out the
> >   document which asserts that the /usr merge is a good thing and pointed
> >   out the thread in which we discussed it on -dev. The arguments
> >   supporting it are strong, and I haven't seen any technical argument
> >   against it that would not be addressed by using an initramfs with
> >   separate /usr. If you are using an initramfs, you will never know
> >   when the /usr merge happens, but if you are using something like
> >   Mike's option your system is not compatible with the merge.
> 
> why exactly do you say that ?  i already explained that busybox[sep-usr] works 
> perfectly fine in a /usr-merged world.  the /ginit static ELF literally needs 
> nothing else in the system to work.  you could boot a rootfs where the only 
> thing in / was ginit and it wouldn't be a problem.

Ah ok, maybe this is the answer then. That's why I said above that I
wasn't sure.

If you are installing the ginit binary directly in /, we may be good
to go. :-)

William




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

Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[William Hubbs]

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

Hi Mike,

On Fri, May 04, 2012 at 09:41:34PM -0500, William Hubbs wrote:
> On Fri, May 04, 2012 at 08:46:21PM -0400, Mike Frysinger wrote:
> > On Friday 04 May 2012 19:06:37 William Hubbs wrote:
> > > If you use an initramfs to pre-mount /usr, all of these issues are moot
> > > and things just work (tm). Mike's sep-usr use flag option on busybox
> > > may do this, but see below.
> > > 
> > > - Separate /usr without initramfs blocks the /usr merge.
> > >   In my original request to have your vote reviewed, I pointed out the
> > >   document which asserts that the /usr merge is a good thing and pointed
> > >   out the thread in which we discussed it on -dev. The arguments
> > >   supporting it are strong, and I haven't seen any technical argument
> > >   against it that would not be addressed by using an initramfs with
> > >   separate /usr. If you are using an initramfs, you will never know
> > >   when the /usr merge happens, but if you are using something like
> > >   Mike's option your system is not compatible with the merge.
> > 
> > why exactly do you say that ?  i already explained that busybox[sep-usr] works 
> > perfectly fine in a /usr-merged world.  the /ginit static ELF literally needs 
> > nothing else in the system to work.  you could boot a rootfs where the only 
> > thing in / was ginit and it wouldn't be a problem.
> 
> Ah ok, maybe this is the answer then. That's why I said above that I
> wasn't sure.
> 
> If you are installing the ginit binary directly in /, we may be good
> to go. :-)

This is pretty slick. I'm running with an initramfs, but I may test your
code here in  a few.

Also, I think I found something I'm going to send you a patch for. I'll
handle that in private email though.

William


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

Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[William Hubbs]

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

Mike and Council members,

It looks like we have two easily supported options now.

1) the initramfs option, and
2) the sep-usr option using busybox.

What I can do when new udev goes stable is put a warning in the udev
ebuild and maybe a news item that explains that, if you have /usr on a
separate partition, you must either:

1) follow the initramfs guide and start using an initramfs or
2) emerge busybox with the sep-usr use flag on and follow the
instructions you receive.

My personal opinion is that we should not mandate one option over the
other, and this is now the only question I feel needs to be clarified.

Thanks for your time,

William


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

Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[Fabian Groffen]

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

On 05-05-2012 00:32:13 -0500, William Hubbs wrote:
[snip]
> ... you must either:
> 
> 1) follow the initramfs guide and start using an initramfs or
> 2) emerge busybox with the sep-usr use flag on and follow the
> instructions you receive.
> 
> My personal opinion is that we should not mandate one option over the
> other, and this is now the only question I feel needs to be clarified.

I don't feel we should mandate anything.

I feel the previous vote was about intentions, not about an actual
implementation.

Fabian


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[William Hubbs]

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

Hi Fabian,

On Sat, May 05, 2012 at 10:32:38AM +0200, Fabian Groffen wrote:
> On 05-05-2012 00:32:13 -0500, William Hubbs wrote:
> [snip]
> > ... you must either:
> > 
> > 1) follow the initramfs guide and start using an initramfs or
> > 2) emerge busybox with the sep-usr use flag on and follow the
> > instructions you receive.
> > 
> > My personal opinion is that we should not mandate one option over the
> > other, and this is now the only question I feel needs to be clarified.
> 
> I don't feel we should mandate anything.
> 
> I feel the previous vote was about intentions, not about an actual
> implementation.

Ok, that's the main reason I brought this up again; I was sort of
feeling otherwise and apparently others were also.

When I read the meeting log, some of the conversation looked like the
council was not only stating that separate /usr was a valid
configuration but mandating that we had to support it a certain way. If
that's not the case, there is really not anything else to discuss for
this. :-)

William


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

Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC

[Donnie Berkholz]

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

On 10:56 Sat 05 May     , William Hubbs wrote:
> When I read the meeting log, some of the conversation looked like the 
> council was not only stating that separate /usr was a valid 
> configuration but mandating that we had to support it a certain way. 
> If that's not the case, there is really not anything else to discuss 
> for this. :-)

I was certainly going out of my way to say the opposite of that. =)

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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