[gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 557 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
discuss or 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 on Tuesday 6th of
November 2012.

Please respond to the gentoo-project list, if possible.

Fabian


-- 
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 13-11-2012

[William Hubbs]

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

Fellow Council Members:

We now have two methods of handling separate /usr configurations on
Linux in the tree.

The first, and by far, the most flexable method is to use an initramfs.
This method is now documented in the initramfs guide [1] and the handbooks.
It would need to be used if a user needs specialized drivers running or
modules loaded before the / or /usr file systems can be accessed.
A non-inclusive list of these situations would be RAID, LVM2, ZFS, and
software for encrypted file systems.

The second method can be used if the flexability of the first method is
not needed. It involves re-emerging >=sys-apps/busybox-1.20.0 with the
sep-usr use flag active and following the instructions in the elog
messages. This is the way to support separate /usr without an initramfs
if someone wants this.

The goal of separate /usr support is to insure that /usr is always
available when / is, and both of these methods meet this goal. If users
switch to one of these methods, there is no further work required by us
to support separate /usr configurations.

I have gone over this with Diego in QA, and he agrees that these are the
methods we should use. That is why he is on the cc: specifically for
this email.

I believe the only remaining step is for the council to approve this
plan, so I would like it to be added to the agenda.

If this is approved, my plan will be to release a news item then
give a time window for users to read the news item and make their
decision [2]. Once the time window expires, we could assume that users
with separate /usr have switched to using one of these two methods of
supporting it.

Thanks,

William

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

[2] I'm thinking a reasonable time window would be 30 days. That could
be up for discussion; however, I don't know of any reasons that we
should wait too much longer.

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

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Ian Stakenvicius]

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

On 30/10/12 11:36 AM, William Hubbs wrote:
> Fellow Council Members:
> 
> We now have two methods of handling separate /usr configurations
> on Linux in the tree.
> 
> The first, and by far, the most flexable method is to use an
> initramfs. This method is now documented in the initramfs guide [1]
> and the handbooks. It would need to be used if a user needs
> specialized drivers running or modules loaded before the / or /usr
> file systems can be accessed. A non-inclusive list of these
> situations would be RAID, LVM2, ZFS, and software for encrypted
> file systems.
> 
> The second method can be used if the flexability of the first
> method is not needed. It involves re-emerging
> >=sys-apps/busybox-1.20.0 with the sep-usr use flag active and
> following the instructions in the elog messages. This is the way to
> support separate /usr without an initramfs if someone wants this.
> 
> The goal of separate /usr support is to insure that /usr is always 
> available when / is, and both of these methods meet this goal. If
> users switch to one of these methods, there is no further work
> required by us to support separate /usr configurations.
> 
> I have gone over this with Diego in QA, and he agrees that these
> are the methods we should use. That is why he is on the cc:
> specifically for this email.
> 
> I believe the only remaining step is for the council to approve
> this plan, so I would like it to be added to the agenda.
> 
> If this is approved, my plan will be to release a news item then 
> give a time window for users to read the news item and make their 
> decision [2]. Once the time window expires, we could assume that
> users with separate /usr have switched to using one of these two
> methods of supporting it.
> 

The end result of this assumption is that the use of
gen_usr_ldscript() and the move of libs from /usr/lib to /lib will
become deprecated, correct?  I think it's pertinent to note this (or
whatever other changes will then be requested/required for Council to
decide on) within this discussion, if not also within the "plan"..



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

iF4EAREIAAYFAlCP/msACgkQ2ugaI38ACPBEWgEAhz3bZDerxT/8bVt+1YzMoeDs
osrzwFXdi+06vF8MTjQBAI79FHc6IO3hjk9kbqD96Urh73zR1WCI2DtlpSypXBvj
=ZgY/
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[William Hubbs]

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

On Tue, Oct 30, 2012 at 12:21:00PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 30/10/12 11:36 AM, William Hubbs wrote:
> > Fellow Council Members:
> > 
> > We now have two methods of handling separate /usr configurations
> > on Linux in the tree.
> > 
> > The first, and by far, the most flexable method is to use an
> > initramfs. This method is now documented in the initramfs guide [1]
> > and the handbooks. It would need to be used if a user needs
> > specialized drivers running or modules loaded before the / or /usr
> > file systems can be accessed. A non-inclusive list of these
> > situations would be RAID, LVM2, ZFS, and software for encrypted
> > file systems.
> > 
> > The second method can be used if the flexability of the first
> > method is not needed. It involves re-emerging
> > >=sys-apps/busybox-1.20.0 with the sep-usr use flag active and
> > following the instructions in the elog messages. This is the way to
> > support separate /usr without an initramfs if someone wants this.
> > 
> > The goal of separate /usr support is to insure that /usr is always 
> > available when / is, and both of these methods meet this goal. If
> > users switch to one of these methods, there is no further work
> > required by us to support separate /usr configurations.
> > 
> > I have gone over this with Diego in QA, and he agrees that these
> > are the methods we should use. That is why he is on the cc:
> > specifically for this email.
> > 
> > I believe the only remaining step is for the council to approve
> > this plan, so I would like it to be added to the agenda.
> > 
> > If this is approved, my plan will be to release a news item then 
> > give a time window for users to read the news item and make their 
> > decision [2]. Once the time window expires, we could assume that
> > users with separate /usr have switched to using one of these two
> > methods of supporting it.
> > 
> 
> The end result of this assumption is that the use of
> gen_usr_ldscript() and the move of libs from /usr/lib to /lib will
> become deprecated, correct?  I think it's pertinent to note this (or
> whatever other changes will then be requested/required for Council to
> decide on) within this discussion, if not also within the "plan"..

On Linux, yes, you are correct. I wouldn't propose touching it for the
*bsd platforms.

Also, once everyone switches over, this deprecation would be
transparent. The calls to gen_usr_ldscript would be removed from
ebuilds where possible, and the function itself could be disabled on
linux. Once this is done, when packages are rebuilt, the libraries would
migrate back to /usr/lib.

William


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

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[William Hubbs]

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

On Tue, Oct 30, 2012 at 11:38:20AM -0500, William Hubbs wrote:
> On Tue, Oct 30, 2012 at 12:21:00PM -0400, Ian Stakenvicius wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> > 
> > On 30/10/12 11:36 AM, William Hubbs wrote:
> > > Fellow Council Members:
> > > 
> > > We now have two methods of handling separate /usr configurations
> > > on Linux in the tree.
> > > 
> > > The first, and by far, the most flexable method is to use an
> > > initramfs. This method is now documented in the initramfs guide [1]
> > > and the handbooks. It would need to be used if a user needs
> > > specialized drivers running or modules loaded before the / or /usr
> > > file systems can be accessed. A non-inclusive list of these
> > > situations would be RAID, LVM2, ZFS, and software for encrypted
> > > file systems.
> > > 
> > > The second method can be used if the flexability of the first
> > > method is not needed. It involves re-emerging
> > > >=sys-apps/busybox-1.20.0 with the sep-usr use flag active and
> > > following the instructions in the elog messages. This is the way to
> > > support separate /usr without an initramfs if someone wants this.
> > > 
> > > The goal of separate /usr support is to insure that /usr is always 
> > > available when / is, and both of these methods meet this goal. If
> > > users switch to one of these methods, there is no further work
> > > required by us to support separate /usr configurations.
> > > 
> > > I have gone over this with Diego in QA, and he agrees that these
> > > are the methods we should use. That is why he is on the cc:
> > > specifically for this email.
> > > 
> > > I believe the only remaining step is for the council to approve
> > > this plan, so I would like it to be added to the agenda.
> > > 
> > > If this is approved, my plan will be to release a news item then 
> > > give a time window for users to read the news item and make their 
> > > decision [2]. Once the time window expires, we could assume that
> > > users with separate /usr have switched to using one of these two
> > > methods of supporting it.
> > > 
> > 
> > The end result of this assumption is that the use of
> > gen_usr_ldscript() and the move of libs from /usr/lib to /lib will
> > become deprecated, correct?  I think it's pertinent to note this (or
> > whatever other changes will then be requested/required for Council to
> > decide on) within this discussion, if not also within the "plan"..
> 
> On Linux, yes, you are correct. I wouldn't propose touching it for the
> *bsd platforms.
> 
> Also, once everyone switches over, this deprecation would be
> transparent. The calls to gen_usr_ldscript would be removed from
> ebuilds where possible, and the function itself could be disabled on
> linux. Once this is done, when packages are rebuilt, the libraries would
> migrate back to /usr/lib.
> 
> William
> 

After further research, we can't implement the initramfs yet for stable
users, because there isn't a stable  version of genkernel which mounts
/usr. So, I would like to change my plan for handling this slightly.

We can't move until a stable version of genkernel supports mounting
/usr. Once that happens, the newsitem will be released and there would
be a time window given, which would be up for discussion, but I think it
should be 30 days.

Other than that, the same proposal stands.

Thanks,

William


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

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Alexis Ballier]

On Tue, 30 Oct 2012 11:38:20 -0500
William Hubbs <williamh@gentoo.org> wrote:

[...]
> > The end result of this assumption is that the use of
> > gen_usr_ldscript() and the move of libs from /usr/lib to /lib will
> > become deprecated, correct?  I think it's pertinent to note this (or
> > whatever other changes will then be requested/required for Council
> > to decide on) within this discussion, if not also within the
> > "plan"..
> 
> On Linux, yes, you are correct. I wouldn't propose touching it for the
> *bsd platforms.
> 
> Also, once everyone switches over, this deprecation would be
> transparent. The calls to gen_usr_ldscript would be removed from
> ebuilds where possible, and the function itself could be disabled on
> linux. Once this is done, when packages are rebuilt, the libraries
> would migrate back to /usr/lib.


(I hadn't seen that thread.)

Removing it from ebuilds implies touching it for *bsd platforms. A lot
of ebuilds are shared between the g/*bsd and g/linux port, that's
somewhat the point of the whole thing. Of course, there may be
linux-only packages where the calls to gen_usr_ldscript will become
useless, but in general these calls should remain and the function
shall be a no-op on platforms where this is desired.

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[William Hubbs]

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

On Thu, Nov 08, 2012 at 02:07:23PM -0300, Alexis Ballier wrote:
> On Tue, 30 Oct 2012 11:38:20 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> [...]
> > > The end result of this assumption is that the use of
> > > gen_usr_ldscript() and the move of libs from /usr/lib to /lib will
> > > become deprecated, correct?  I think it's pertinent to note this (or
> > > whatever other changes will then be requested/required for Council
> > > to decide on) within this discussion, if not also within the
> > > "plan"..
> > 
> > On Linux, yes, you are correct. I wouldn't propose touching it for the
> > *bsd platforms.
> > 
> > Also, once everyone switches over, this deprecation would be
> > transparent. The calls to gen_usr_ldscript would be removed from
> > ebuilds where possible, and the function itself could be disabled on
> > linux. Once this is done, when packages are rebuilt, the libraries
> > would migrate back to /usr/lib.
> 
> 
> (I hadn't seen that thread.)
> 
> Removing it from ebuilds implies touching it for *bsd platforms. A lot
> of ebuilds are shared between the g/*bsd and g/linux port, that's
> somewhat the point of the whole thing. Of course, there may be
> linux-only packages where the calls to gen_usr_ldscript will become
> useless, but in general these calls should remain and the function
> shall be a no-op on platforms where this is desired.
 
 That's what I said. The calls could be removed "where possible",
 meaning linux-only ebuilds. You can tell from the KEYWORDS which
 ebuilds this would apply to. :-)

William


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

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Chí-Thanh Christopher Nguyễn]

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

Dear all,

I wish to ask that the council makes a statement regarding the policy
on "<" versioned dependencies.

Some time ago one of the ebuilds that I maintain was removed twice
without my consent, the reason given that it violates an alleged
policy which forbids <sys-kernel/linux-headers-2.6.38 dependency[1].
After some discussion, the issue was resolved by fixing the build with
newer linux-headers. About the policy itself, no consensus was reached.

The issue came up again later[2] and also recently with some x11
maintained packages[3]. Today in the boost discussion thread on -dev
it was brought up too.

If I understand correctly, the proponents of this policy call for some
kind of reverse visibility requirements, where stabilizing or
unmasking a package requires all reverse dependencies on that slot to
work with the newly stabilized/unmasked version.

I dispute that such a policy exists, and am not aware of any
authoritative document that says so. When asking for documents that
describe this policy, I was only pointed to common sense.

The reason why I think that < dependencies are not bad is that
existing users of such packages will typically simply miss out on
upgrades. Worst case is that trying to newly install a package can
lead to downgrades or slot conflicts. But the user can see this before
the build starts, and still decide to abort or uninstall one of the
problem packages.

The reason why I think that forbidding < dependencies is bad is that
in the case of x11 maintained packages, their development speed is
non-uniform. Especially new xorg-server releases can have certain
x11-drivers packages depend on old versions for weeks or even months.
Masking xorg-server will hinder X.org progress for everyone else, and
removing the drivers that continue to work fine with old xorg-server
would be a disservice to users.

I therefore ask the council to:
1. State whether such a policy exists
2. If it exists, repeal this policy
3. If the policy exists and is not repealed, state what is done with
packages in violation of that policy (e.g. must they be treecleaned,
or is it sufficient to p.mask them or drop to ~arch?)


Best regards,
Chí-Thanh Christopher Nguyễn


[1] https://bugs.gentoo.org/show_bug.cgi?id=361181
[2] https://bugs.gentoo.org/show_bug.cgi?id=414997
[3] https://bugs.gentoo.org/show_bug.cgi?id=439714
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCQT2YACgkQ+gvH2voEPRB7OACePIMpS1g/G3vQ/yUp2/ngSMVB
1W0AnRANyPZoANZ8mW4ErjcrwS/+wSuH
=mzoU
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Ciaran McCreesh]

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

On Tue, 30 Oct 2012 23:06:30 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> The reason why I think that < dependencies are not bad is that
> existing users of such packages will typically simply miss out on
> upgrades.

No, what will happen is that Portage will perform the upgrades anyway
and break things, since it doesn't check dependencies of installed
packages that aren't part of the resolution.

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

iEYEARECAAYFAlCQUB8ACgkQ96zL6DUtXhFJUwCgiTEeYHRcz+AkQh/X0MI978OC
T24An0txxAh3T7u95c3nr9KUEnAcDIb/
=sCDP
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Chí-Thanh Christopher Nguyễn]

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

Ciaran McCreesh schrieb:
> On Tue, 30 Oct 2012 23:06:30 +0100 Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>> The reason why I think that < dependencies are not bad is that 
>> existing users of such packages will typically simply miss out
>> on upgrades.
> 
> No, what will happen is that Portage will perform the upgrades
> anyway and break things, since it doesn't check dependencies of
> installed packages that aren't part of the resolution.

Do you have a test case for this? I haven't observed this in recent times.


Best regards,
Chí-Thanh Christopher Nguyễn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCQUKEACgkQ+gvH2voEPRCa7ACeJoJU+OVcYlsqHNbdlZzWj6KW
vfsAn0fDzGzs/PSCZ74jgijdOezJ/UZg
=pkHx
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Zac Medico]

On 10/30/2012 03:11 PM, Chí-Thanh Christopher Nguyễn wrote:
> Ciaran McCreesh schrieb:
>> On Tue, 30 Oct 2012 23:06:30 +0100 Chí-Thanh Christopher Nguyễn
>> <chithanh@gentoo.org> wrote:
>>> The reason why I think that < dependencies are not bad is that 
>>> existing users of such packages will typically simply miss out
>>> on upgrades.
> 
>> No, what will happen is that Portage will perform the upgrades
>> anyway and break things, since it doesn't check dependencies of
>> installed packages that aren't part of the resolution.
> 
> Do you have a test case for this? I haven't observed this in recent times.

It should not be an issue since portage-2.1.10.21, which had the
--complete-graph-if-new-ver enabled by default:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=2733ea17d8e25db8dd369e8890337ddb553e2509
-- 
Thanks,
Zac

Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Pacho Ramos]

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

El mar, 30-10-2012 a las 23:06 +0100, Chí-Thanh Christopher Nguyễn
escribió:
[...]
> The reason why I think that forbidding < dependencies is bad is that
> in the case of x11 maintained packages, their development speed is
> non-uniform. Especially new xorg-server releases can have certain
> x11-drivers packages depend on old versions for weeks or even months.
> Masking xorg-server will hinder X.org progress for everyone else, and
> removing the drivers that continue to work fine with old xorg-server
> would be a disservice to users.
> 
> I therefore ask the council to:
> 1. State whether such a policy exists
> 2. If it exists, repeal this policy
> 3. If the policy exists and is not repealed, state what is done with
> packages in violation of that policy (e.g. must they be treecleaned,
> or is it sufficient to p.mask them or drop to ~arch?)
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 

I understand your point and agree


[...]
> [3] https://bugs.gentoo.org/show_bug.cgi?id=439714


But in this case, it's really trivial to fix (stabilize missing drivers)
and that will benefit all people, don't seeing a blocker, this is the
reason for me filling a bug for it and not for other xorg stuff that are
much harder to handle.

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