[gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Fabian Groffen]

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

The next council meeting will be on Tuesday 11 November 2012 at 19:00 UTC
in the #gentoo-council channel on Freenode.


Proposed agenda:

1. Introduction and roll call (5 minutes)

2. Handling separate /usr support[1] (15 minutes)
   - approve/disapprove plan (forcing everyone to take action, and
     implement one of the two "supported" solutions)
   - approve/disapprove removal of gen_usr_ldscript
   - define timeframe
     * 30 days
     * 6 months
     * 1 year

3. Policy on "<" versioned dependencies[2] (5 minutes)
   - state whether said policy exists (homework for the council members)

4. Open bugs with council involvement (5 minutes)
   - Bug 383467 "Council webpage lacks results for 2010 and 2011
     elections"
   - Bug 438338 "Please update devmanual with EAPI5 info"
                                                                                
5. Open floor (10 minutes)


Fabian


[1] http://thread.gmane.org/gmane.linux.gentoo.project/2208
[2] http://thread.gmane.org/gmane.linux.gentoo.project/2213

-- 
Fabian Groffen
Gentoo on a different level

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

[gentoo-project] Re: [gentoo-dev-announce] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Alexis Ballier]

On Tue, 6 Nov 2012 22:28:16 +0100
Fabian Groffen <grobian@gentoo.org> wrote:

> 2. Handling separate /usr support[1] (15 minutes)
>    - approve/disapprove plan (forcing everyone to take action, and
>      implement one of the two "supported" solutions)

Note: not every bootable gentoo system is linux + udev based (or
whatever is the reason for this deprecation). From what I know, FreeBSD
has no plan to deprecate separate /usr and neither does our
Gentoo/FreeBSD port.

>    - approve/disapprove removal of gen_usr_ldscript

I'm not sure what you meant here, but if that meant 'make it a no-op on
systems where it makes sense', then fine by me. Otherwise, please keep
in mind that removing it will also affect g/fbsd where this is still
needed in order to have a sane / and /usr separation.

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

All,

I would like to add information wrt the separate /usr issue.

On Tue, Nov 06, 2012 at 10:28:16PM +0100, Fabian Groffen wrote:
> 2. Handling separate /usr support[1] (15 minutes)
>    - approve/disapprove plan (forcing everyone to take action, and
>      implement one of the two "supported" solutions)

The tracker bug [1] shows what we are still waiting for in order to
implement this plan. Mostly now it is just stabilizations. It also shows
the things that can't go forward without it. One thing is udev stabilization;
however, this also blocks udisks:2 which is used by at least newer versions of
gnome and XFCE, so we are preventing those from going stable.

>    - approve/disapprove removal of gen_usr_ldscript

A better way to put this is disabling gen_usr_ldscript on Linux.
Some of the alternate platforms still use it, so I do not advocate
killing the function.
If we go forward with the plan, there is no reason the council should
reject disabling gen_usr_ldscript on Linux that I am aware of.

This also has to wait until the blockers are resolved on the tracker.

>    - define timeframe
>      * 30 days
>      * 6 months
>      * 1 year
 
Once the blockers are done and we release a news item, implementing
one of the choices is a matter of emerging a package, possibly running a
command (genkernel with the appropriate options) and updating your boot
loader configuration before your next reboot.

Considering that we are holding back stabilizations of more and more
packages the longer we wait, is it really a good idea to extend the time
frame to 6 months or a year?

It is true that udev/udisks have had a hand in bringing separate /usr to
the forefront this time; however, it was brought to the forefront 10
years ago by the toolchain [2].

There is at least one other issue I can think of that is technically
broken but fails gracefully with mounting /usr late in Linux.
That issue is locales since the information for them is in /usr/share/locale.
This also becomes a non-issue as soon as we implement this plan.

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=411627
[2] https://bugs.gentoo.org/show_bug.cgi?id=4411

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

Re: [gentoo-project] Re: [gentoo-dev-announce] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Rich Freeman]

On Thu, Nov 8, 2012 at 11:30 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Tue, 6 Nov 2012 22:28:16 +0100
> Fabian Groffen <grobian@gentoo.org> wrote:
>>    - approve/disapprove removal of gen_usr_ldscript
>
> I'm not sure what you meant here, but if that meant 'make it a no-op on
> systems where it makes sense', then fine by me. Otherwise, please keep
> in mind that removing it will also affect g/fbsd where this is still
> needed in order to have a sane / and /usr separation.

I haven't really seen any discussion of this so I'll chime in.

Up until now most of the discussion has been about ALLOWING
maintainers to stick boot-required files in /usr at some point in the
future.  Changing things like gen_usr_ldscript would actually
represent an active push towards moving these files into /usr.  I
think that is a big distinction, and it would cause our Linux vs BSD
approaches to diverge unless we forced BSD to follow along.

I think there is a difference between allowing a few Linux-only
packages to move to /usr to follow upstream and moving towards a full
scale /usr migration on Linux for all packages, even if their
upstreams don't use /usr.

I think the more conservative approach is to take things one step at a
time - after some period of time allow things to move to /usr, but
leave it up to maintainer discretion, since they're the ones getting
bugs from linux, BSD, etc.

Rich

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Fabian Groffen]

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

On 08-11-2012 11:45:48 -0600, William Hubbs wrote:
> >    - approve/disapprove removal of gen_usr_ldscript
> 
> A better way to put this is disabling gen_usr_ldscript on Linux.
> Some of the alternate platforms still use it, so I do not advocate
> killing the function.
> If we go forward with the plan, there is no reason the council should
> reject disabling gen_usr_ldscript on Linux that I am aware of.
> 
> This also has to wait until the blockers are resolved on the tracker.

Do you suggest to drop the point from the agenda?  I'd love that.

> >    - define timeframe
> >      * 30 days
> >      * 6 months
> >      * 1 year
>  
> Once the blockers are done and we release a news item, implementing
> one of the choices is a matter of emerging a package, possibly running a
> command (genkernel with the appropriate options) and updating your boot
> loader configuration before your next reboot.
> 
> Considering that we are holding back stabilizations of more and more
> packages the longer we wait, is it really a good idea to extend the time
> frame to 6 months or a year?

Yes.  I don't think it is reasonable to have a very short timeframe for
having to make such a potentially dangerous change.

Fabian


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Re: [gentoo-dev-announce] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

On Thu, Nov 08, 2012 at 12:46:20PM -0500, Rich Freeman wrote:
> On Thu, Nov 8, 2012 at 11:30 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> > On Tue, 6 Nov 2012 22:28:16 +0100
> > Fabian Groffen <grobian@gentoo.org> wrote:
> >>    - approve/disapprove removal of gen_usr_ldscript
> >
> > I'm not sure what you meant here, but if that meant 'make it a no-op on
> > systems where it makes sense', then fine by me. Otherwise, please keep
> > in mind that removing it will also affect g/fbsd where this is still
> > needed in order to have a sane / and /usr separation.
> 
> I haven't really seen any discussion of this so I'll chime in.
> 
> Up until now most of the discussion has been about ALLOWING
> maintainers to stick boot-required files in /usr at some point in the
> future.  Changing things like gen_usr_ldscript would actually
> represent an active push towards moving these files into /usr.  I
> think that is a big distinction, and it would cause our Linux vs BSD
> approaches to diverge unless we forced BSD to follow along.
 
 There's no reason to make *bsd do anything. gen_usr_ldscript is already
 smart enough to not do anything in some environments; I'm just
 proposing adding linux to that list.

> I think there is a difference between allowing a few Linux-only
> packages to move to /usr to follow upstream and moving towards a full
> scale /usr migration on Linux for all packages, even if their
> upstreams don't use /usr.
 
 I'm not talking about migrating *anything* at this point, just how to
 implement separate /usr support on linux, without affecting what the
 alternate platforms are doing.

> I think the more conservative approach is to take things one step at a
> time - after some period of time allow things to move to /usr, but
> leave it up to maintainer discretion, since they're the ones getting
> bugs from linux, BSD, etc.

Please let's keep this thread on topic. Migrating packages is another
separate discussion.

Thanks,

William


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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen wrote:
> On 08-11-2012 11:45:48 -0600, William Hubbs wrote:
> > >    - approve/disapprove removal of gen_usr_ldscript
> > 
> > A better way to put this is disabling gen_usr_ldscript on Linux.
> > Some of the alternate platforms still use it, so I do not advocate
> > killing the function.
> > If we go forward with the plan, there is no reason the council should
> > reject disabling gen_usr_ldscript on Linux that I am aware of.
> > 
> > This also has to wait until the blockers are resolved on the tracker.
> 
> Do you suggest to drop the point from the agenda?  I'd love that.
 
I believe we can drop the gen_usr_ldscript question, yes, because if
everything else happens, we can just have the toolchain guys make it a
noop on Linux.

> > >    - define timeframe
> > >      * 30 days
> > >      * 6 months
> > >      * 1 year
> >  
> > Once the blockers are done and we release a news item, implementing
> > one of the choices is a matter of emerging a package, possibly running a
> > command (genkernel with the appropriate options) and updating your boot
> > loader configuration before your next reboot.
> > 
> > Considering that we are holding back stabilizations of more and more
> > packages the longer we wait, is it really a good idea to extend the time
> > frame to 6 months or a year?
> 
> Yes.  I don't think it is reasonable to have a very short timeframe for
> having to make such a potentially dangerous change.

I agree that this is a potentially dangerous change. However, I don't think it
is reasonable for us to penalize stable users by making them wait a year for
newer software because we are waiting to make sure that those who have
a separate mount for /usr make a change that we can't make for them
automatically.

I would be ok with going a little longer than 30 days, but 6 months or
a year might be a bit extreme.

I guess I'm just thinking that no matter how long we wait, there is
going to be someone out there who isn't going to follow our directions.

William


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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Rich Freeman]

Summarizing some irc discussion:

On Thu, Nov 8, 2012 at 1:53 PM, William Hubbs <williamh@gentoo.org> wrote:
> I believe we can drop the gen_usr_ldscript question, yes, because if
> everything else happens, we can just have the toolchain guys make it a
> noop on Linux.

There is disagreement over whether this is a good idea.  Nobody
objects to dropping gen_usr_ldscript from discussion if it is left
alone, but it probably deserves some kind of consideration if we want
to change it (maybe not a council vote, but at least discussion).

I think that the direction Gentoo wants to move in has no clear
consensus.  I see several options:
1.  All boot-time files are in / (the old position, which we've agreed
to move away from).
2.  Files can be in / or /usr at maintainer discretion (align with
upstream, etc).
3.  All files should be in /usr - eventually /bin, /lib, and so on
should be empty (where Fedora is going).

Dropping support for separate /usr without one of the solutions
already discussed is making the move from #1 to #2.  I see modifying
gen_usr_ldscript as making the step from #2 to #3.

Personally I don't have a problem with the /usr move, but that is a
big step, and I don't want to see lots of files moving to /usr without
maintainer involvement unless we're REALLY sure we want that.  Also,
before that function is modified to be a no-op on linux we should do
some serious testing - a lot of very important packages are going to
be affected.

And of course this only affects libraries - movement of anything else
will require ebuild changes.

>
> I would be ok with going a little longer than 30 days, but 6 months or
> a year might be a bit extreme.

That was my thought as well - maybe 60 or 90 days is a better option.
Even 30 days though is a fair bit of time to migrate to initramfs.  We
can always send out a news item that this is coming now if anybody
wants to mess with ~arch packages on a test machine before things are
stabilized.

Rich

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

On Thu, Nov 08, 2012 at 04:16:35PM -0500, Rich Freeman wrote:
> Summarizing some irc discussion:
> 
> On Thu, Nov 8, 2012 at 1:53 PM, William Hubbs <williamh@gentoo.org> wrote:
> > I believe we can drop the gen_usr_ldscript question, yes, because if
> > everything else happens, we can just have the toolchain guys make it a
> > noop on Linux.
> 
> There is disagreement over whether this is a good idea.  Nobody
> objects to dropping gen_usr_ldscript from discussion if it is left
> alone, but it probably deserves some kind of consideration if we want
> to change it (maybe not a council vote, but at least discussion).
> 
> I think that the direction Gentoo wants to move in has no clear
> consensus.  I see several options:
> 1.  All boot-time files are in / (the old position, which we've agreed
> to move away from).
> 2.  Files can be in / or /usr at maintainer discretion (align with
> upstream, etc).
> 3.  All files should be in /usr - eventually /bin, /lib, and so on
> should be empty (where Fedora is going).
> 
> Dropping support for separate /usr without one of the solutions
> already discussed is making the move from #1 to #2.  I see modifying
> gen_usr_ldscript as making the step from #2 to #3.

No, it is part of the step from #1 to #2, since gen_usr_ldscript only
moves shared libraries. If we turn this off, we end up leaving shared
libraries where upstream intended them to be instead of putting them in
/ and separating them from the static libraries.

> Personally I don't have a problem with the /usr move, but that is a
> big step, and I don't want to see lots of files moving to /usr without
> maintainer involvement unless we're REALLY sure we want that.

I'm not advocating right now for the /usr move, just what you called
step #1 to #2.

> Also,
> before that function is modified to be a no-op on linux we should do
> some serious testing - a lot of very important packages are going to
> be affected.
 
 I do agree with testing, but this will all come after we implement
 separate /usr support; otherwise the testing will fail if you have
 separate /usr.

> And of course this only affects libraries - movement of anything else
> will require ebuild changes.
 
 Actually it only affects shared libraries.

> > I would be ok with going a little longer than 30 days, but 6 months or
> > a year might be a bit extreme.
> 
> That was my thought as well - maybe 60 or 90 days is a better option.
> Even 30 days though is a fair bit of time to migrate to initramfs.  We
> can always send out a news item that this is coming now if anybody
> wants to mess with ~arch packages on a test machine before things are
> stabilized.

I have to get a new openrc stable and we need a newer genkernel before
anything can start stabilizing. I don't want to send out  any newsitems
yet; I want to wait until the council says go ahead with this, and
probably I'll send it out when that happens and we have the newer openrc
and genkernel stabled and give a time window then.

Also, if you don't want to use initramfs, you can use busybox[sep-usr].
Emerge it with that use flag and follow the instructions you get.
William


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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Rich Freeman]

On Thu, Nov 8, 2012 at 5:09 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Thu, Nov 08, 2012 at 04:16:35PM -0500, Rich Freeman wrote:
>> I think that the direction Gentoo wants to move in has no clear
>> consensus.  I see several options:
>> 1.  All boot-time files are in / (the old position, which we've agreed
>> to move away from).
>> 2.  Files can be in / or /usr at maintainer discretion (align with
>> upstream, etc).
>> 3.  All files should be in /usr - eventually /bin, /lib, and so on
>> should be empty (where Fedora is going).
>>
>> Dropping support for separate /usr without one of the solutions
>> already discussed is making the move from #1 to #2.  I see modifying
>> gen_usr_ldscript as making the step from #2 to #3.
>
> No, it is part of the step from #1 to #2, since gen_usr_ldscript only
> moves shared libraries. If we turn this off, we end up leaving shared
> libraries where upstream intended them to be instead of putting them in
> / and separating them from the static libraries.
>

I think this is a matter of one saying tomato, and another saying tomato.  :)

However, the end result is that after making the proposed change lots
of stuff that is currently being installed in / will end up installed
in /usr.  Sure, that might be how upstream intended it, but it is a
change all the same.  If maintainers are comfortable with it no harm
in doing it with testing.

I haven't really seen any complaints per-se.  I'd love to hear from
package maintainers that use gen_usr_ldscript either way.  I wouldn't
be one to oppose the change, but I just wanted to make sure that
everybody was aware of the consequences.

Rich

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Alexis Ballier]

On Thu, 8 Nov 2012 12:53:48 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen wrote:
> > On 08-11-2012 11:45:48 -0600, William Hubbs wrote:
> > > >    - approve/disapprove removal of gen_usr_ldscript
> > > 
> > > A better way to put this is disabling gen_usr_ldscript on Linux.
> > > Some of the alternate platforms still use it, so I do not advocate
> > > killing the function.
> > > If we go forward with the plan, there is no reason the council
> > > should reject disabling gen_usr_ldscript on Linux that I am aware
> > > of.
> > > 
> > > This also has to wait until the blockers are resolved on the
> > > tracker.
> > 
> > Do you suggest to drop the point from the agenda?  I'd love that.
>  
> I believe we can drop the gen_usr_ldscript question, yes, because if
> everything else happens, we can just have the toolchain guys make it a
> noop on Linux.

Something simpler and smoother imho is to just have a profile variable
that will make gen_usr_ldscript a noop, whatever CHOST or the kernel is.
New profiles are added with this variable set, wide testing can be done
without forcing anyone, and voila. It is also simpler for maintaining
the various OSes, packages that used to install to / can just be
changed to install to /usr when this variable is set.

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

On Thu, Nov 08, 2012 at 08:46:29PM -0300, Alexis Ballier wrote:
> On Thu, 8 Nov 2012 12:53:48 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen wrote:
> > > On 08-11-2012 11:45:48 -0600, William Hubbs wrote:
> > > > >    - approve/disapprove removal of gen_usr_ldscript
> > > > 
> > > > A better way to put this is disabling gen_usr_ldscript on Linux.
> > > > Some of the alternate platforms still use it, so I do not advocate
> > > > killing the function.
> > > > If we go forward with the plan, there is no reason the council
> > > > should reject disabling gen_usr_ldscript on Linux that I am aware
> > > > of.
> > > > 
> > > > This also has to wait until the blockers are resolved on the
> > > > tracker.
> > > 
> > > Do you suggest to drop the point from the agenda?  I'd love that.
> >  
> > I believe we can drop the gen_usr_ldscript question, yes, because if
> > everything else happens, we can just have the toolchain guys make it a
> > noop on Linux.
> 
> Something simpler and smoother imho is to just have a profile variable
> that will make gen_usr_ldscript a noop, whatever CHOST or the kernel is.
> New profiles are added with this variable set, wide testing can be done
> without forcing anyone, and voila. It is also simpler for maintaining
> the various OSes, packages that used to install to / can just be
> changed to install to /usr when this variable is set.

I'm not trying to make packages install in /usr with this change.

gen_usr_ldscript was introduced to force shaired libraries that upstream
installs into /usr/lib to move to /lib and leave the static libraries in
/usr/lib.

So, gentoo linux is diverging from upstream's install locations by
splitting up where we install libraries. All I'm proposing is that on
linux we should remove that divergance and put libraries where upstream
installs them.

Since we can tell we are on linux by looking at the chost/ctarget
variables, and there is not an intention to change anything for *bsd or
any other O/S, I am not sure I follow the need for a profile variable.

Again, I'm not asking that the council vote on this at this vote, I am
just asking that they approve the two methods of supporting separate
/usr on linux and approve the action plan of putting out a newsitem and
giving a time window for everyone to migrate to either initramfs or
busybox[sep-usr].

If they want to discuss the gen_usr_ldscript issue I'm not opposed to
that, but that isn't really what I am asking for in this meeting.

William


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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Fabian Groffen]

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

On 08-11-2012 20:46:29 -0300, Alexis Ballier wrote:
> > > Do you suggest to drop the point from the agenda?  I'd love that.
> >  
> > I believe we can drop the gen_usr_ldscript question, yes, because if
> > everything else happens, we can just have the toolchain guys make it a
> > noop on Linux.
> 
> Something simpler and smoother imho is to just have a profile variable
> that will make gen_usr_ldscript a noop, whatever CHOST or the kernel is.
> New profiles are added with this variable set, wide testing can be done
> without forcing anyone, and voila. It is also simpler for maintaining
> the various OSes, packages that used to install to / can just be
> changed to install to /usr when this variable is set.

+1
That is what we currently do in Prefix.  The plan is to enable it for
new installs.  Just waiting at the moment because we horribly break
systems when we change the behaviour of gen_usr_ldscript on an existing
system.

For Gentoo Linux, since I don't run udev (any more) and my systems are
servers, I'll never have the need for any of this, so with that approach
I could simply keep my system as is, no risks imposed by moving crucial
libs around, and no problem for people that want to stabilise udev,
GNOME, whatever, since those packages could even be masked.


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Rich Freeman]

On Fri, Nov 9, 2012 at 12:13 AM, William Hubbs <williamh@gentoo.org> wrote:
> I'm not trying to make packages install in /usr with this change.
>...
> All I'm proposing is that on
> linux we should remove that divergance and put libraries where upstream
> installs them.

Ok, you're not proposing that we move stuff to /usr.  You're proposing
that we stop moving stuff from /usr to / so that they end up in /usr
just the same.  Whatever.

>
> Since we can tell we are on linux by looking at the chost/ctarget
> variables, and there is not an intention to change anything for *bsd or
> any other O/S, I am not sure I follow the need for a profile variable.

I think the profile variable is a very good suggestion.  This allows
us to tune the behavior without hard-coding it, and it allows some
kind of testing/migration path.

I think that any changes need to be discussed a bit more broadly.  I'm
actually supportive of the /usr move in general, but for the number of
complaints it has gotten I'm a bit surprised to not have seen more on
this thread.  Maybe nobody reads -project.

Whether it is by the general dev community or the council I think
making any changes to something like gen_usr_ldscript needs good
awareness, testing, and feedback.  As has already been pointed out, we
need to really be careful about the migration path since you're
talking about a potential revdep-rebuild for all kinds of packages.

Rich

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Alexis Ballier]

On Thu, 8 Nov 2012 23:13:46 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Thu, Nov 08, 2012 at 08:46:29PM -0300, Alexis Ballier wrote:
> > On Thu, 8 Nov 2012 12:53:48 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> > > On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen wrote:
> > > > On 08-11-2012 11:45:48 -0600, William Hubbs wrote:
> > > > > >    - approve/disapprove removal of gen_usr_ldscript
> > > > > 
> > > > > A better way to put this is disabling gen_usr_ldscript on
> > > > > Linux. Some of the alternate platforms still use it, so I do
> > > > > not advocate killing the function.
> > > > > If we go forward with the plan, there is no reason the council
> > > > > should reject disabling gen_usr_ldscript on Linux that I am
> > > > > aware of.
> > > > > 
> > > > > This also has to wait until the blockers are resolved on the
> > > > > tracker.
> > > > 
> > > > Do you suggest to drop the point from the agenda?  I'd love
> > > > that.
> > >  
> > > I believe we can drop the gen_usr_ldscript question, yes, because
> > > if everything else happens, we can just have the toolchain guys
> > > make it a noop on Linux.
> > 
> > Something simpler and smoother imho is to just have a profile
> > variable that will make gen_usr_ldscript a noop, whatever CHOST or
> > the kernel is. New profiles are added with this variable set, wide
> > testing can be done without forcing anyone, and voila. It is also
> > simpler for maintaining the various OSes, packages that used to
> > install to / can just be changed to install to /usr when this
> > variable is set.
> 
> I'm not trying to make packages install in /usr with this change.

You are, since if a package in / needs a shared lib in /usr, there is
absolutely no point in installing the package in /.
nooping gen_usr_ldscript should come with a kind of plan for the /usr
move otherwise it is a bit ugly and somewhat loses its point.

> gen_usr_ldscript was introduced to force shaired libraries that
> upstream installs into /usr/lib to move to /lib and leave the static
> libraries in /usr/lib.

It's rather the opposite actually: very few upstream specify their
install location, most default to /usr/local prefix because that's
autotools default. econf (ie us) sets the prefix to /usr.
gen_usr_ldscript is there because we don't need the static lib in / (so
that setting libdir to /lib is not an option) while the shared lib is
needed by binaries in /. We could just move the shared lib to / but
then the linker may link to the static lib if /usr/lib comes
before /lib in its search order, so we need a .so in the same dir as
the .a. For example FreeBSD solved that differently: they
symlink /lib/libfoo.so to /usr/lib/libfoo.so. Years ago we deemed
symlinks crossing the /usr barrier were bad, and here comes
gen_usr_ldscript. Note that I don't really see the difference between a
symlink crossing the /usr barrier and a ldscript referencing a file
outside of /usr but there must be some argument behind.

> So, gentoo linux is diverging from upstream's install locations by
> splitting up where we install libraries. All I'm proposing is that on
> linux we should remove that divergance and put libraries where
> upstream installs them.

Let's move everything to /usr/local :) there is not really a 'where
upstream installs them' argument in this discussion, autotools is
specifically designed so that distributions can tweak the install
location. The fact that both the static and shared libs go to libdir is
only a shortcoming of autotools, some other build systems make the
distinction.

> Since we can tell we are on linux by looking at the chost/ctarget
> variables, and there is not an intention to change anything for *bsd
> or any other O/S, I am not sure I follow the need for a profile
> variable.

Testing it. Testing the /usr move broadly.
You want gen_usr_ldscript on non-bootable systems (eg prefix, mingw) to
be (mostly) a noop too which you can't distinguish from only CHOST.

> Again, I'm not asking that the council vote on this at this vote, I am
> just asking that they approve the two methods of supporting separate
> /usr on linux and approve the action plan of putting out a newsitem
> and giving a time window for everyone to migrate to either initramfs
> or busybox[sep-usr].

Fair enough :)

> If they want to discuss the gen_usr_ldscript issue I'm not opposed to
> that, but that isn't really what I am asking for in this meeting.

IMHO this needs a discussion on -dev before going through the council.

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

On Fri, Nov 09, 2012 at 08:33:55AM -0300, Alexis Ballier wrote:
> On Thu, 8 Nov 2012 23:13:46 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > On Thu, Nov 08, 2012 at 08:46:29PM -0300, Alexis Ballier wrote:
> > > On Thu, 8 Nov 2012 12:53:48 -0600
> > > William Hubbs <williamh@gentoo.org> wrote:
> > > 
> > > > On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen wrote:
> > > > > On 08-11-2012 11:45:48 -0600, William Hubbs wrote:
> > > > > > >    - approve/disapprove removal of gen_usr_ldscript
> > > > > > 
> > > > > > A better way to put this is disabling gen_usr_ldscript on
> > > > > > Linux. Some of the alternate platforms still use it, so I do
> > > > > > not advocate killing the function.
> > > > > > If we go forward with the plan, there is no reason the council
> > > > > > should reject disabling gen_usr_ldscript on Linux that I am
> > > > > > aware of.
> > > > > > 
> > > > > > This also has to wait until the blockers are resolved on the
> > > > > > tracker.
> > > > > 
> > > > > Do you suggest to drop the point from the agenda?  I'd love
> > > > > that.
> > > >  
> > > > I believe we can drop the gen_usr_ldscript question, yes, because
> > > > if everything else happens, we can just have the toolchain guys
> > > > make it a noop on Linux.
> > > 
> > > Something simpler and smoother imho is to just have a profile
> > > variable that will make gen_usr_ldscript a noop, whatever CHOST or
> > > the kernel is. New profiles are added with this variable set, wide
> > > testing can be done without forcing anyone, and voila. It is also
> > > simpler for maintaining the various OSes, packages that used to
> > > install to / can just be changed to install to /usr when this
> > > variable is set.
> > 
> > I'm not trying to make packages install in /usr with this change.
> 
> You are, since if a package in / needs a shared lib in /usr, there is
> absolutely no point in installing the package in /.
> nooping gen_usr_ldscript should come with a kind of plan for the /usr
> move otherwise it is a bit ugly and somewhat loses its point.
 
No. All of this discussion about turning off gen_usr_ldscript on linux
applies *after* separate /usr support (either by an initramfs or with
the busybox[sep-usr] option) is implemented. Once one of these options
is implemented, /usr is always available when / is, so the "barrier" between
/ and /usr no longer exists. That just means you don't need to move
shared libraries to / for binaries in / to link to them. It is the same
as if you didn't put /usr on its own partition. To me, your argument
here about disabling gen_usr_ldscript is like saying, if you put / and
/usr on the same partition you should do a /usr move.

> > gen_usr_ldscript was introduced to force shaired libraries that
> > upstream installs into /usr/lib to move to /lib and leave the static
> > libraries in /usr/lib.
> 
> It's rather the opposite actually: very few upstream specify their
> install location, most default to /usr/local prefix because that's
> autotools default. econf (ie us) sets the prefix to /usr.
> gen_usr_ldscript is there because we don't need the static lib in / (so
> that setting libdir to /lib is not an option) while the shared lib is
> needed by binaries in /. We could just move the shared lib to / but
> then the linker may link to the static lib if /usr/lib comes
> before /lib in its search order, so we need a .so in the same dir as
> the .a. For example FreeBSD solved that differently: they
> symlink /lib/libfoo.so to /usr/lib/libfoo.so. Years ago we deemed
> symlinks crossing the /usr barrier were bad, and here comes
> gen_usr_ldscript. Note that I don't really see the difference between a
> symlink crossing the /usr barrier and a ldscript referencing a file
> outside of /usr but there must be some argument behind.

I spoke to flameeyes about symlinks crossing the /usr barrier, wrt
another package, and he doesn't have a problem with this. I also have never
seen any policy etc deaming them bad, but that's another discussion.

All I'm saying is that implementing separate /usr support on linux
eliminates the /->/usr barrier since / and /usr are always available at
the same time, thus eliminating the need for gen_usr_ldscript.

> Let's move everything to /usr/local :) there is not really a 'where
> upstream installs them' argument in this discussion, autotools is
> specifically designed so that distributions can tweak the install
> location. The fact that both the static and shared libs go to libdir is
> only a shortcoming of autotools, some other build systems make the
> distinction.
 
I'm not familiar with many other build systems, so I can't really
comment specifically to this. But, I wonder why you would need to
separate where static and shared libs are installed.

> > Since we can tell we are on linux by looking at the chost/ctarget
> > variables, and there is not an intention to change anything for *bsd
> > or any other O/S, I am not sure I follow the need for a profile
> > variable.
> 
> Testing it. Testing the /usr move broadly.
> You want gen_usr_ldscript on non-bootable systems (eg prefix, mingw) to
> be (mostly) a noop too which you can't distinguish from only CHOST.

That has been done already by toolchain a while back. Take a look at the
code in toolchain-funcs.eclass. There are very few platforms where this
function does anything at all these days. It would just be a matter of
removing linux from the platforms it supports.

Once again, this has nothing to do with the /usr move, just eliminating
the /->/usr barrier.

> > If they want to discuss the gen_usr_ldscript issue I'm not opposed to
> > that, but that isn't really what I am asking for in this meeting.
> 
> IMHO this needs a discussion on -dev before going through the council.
 
 I would send the patch to do this to -dev anyway, so at that time I
 guess we could have folks apply it and rebuild their systems and see
 what breaks.

 Since applying the patch itself will not force any rebuilds, it should
 just end up being a natural migration; as things are rebuilt the
 libraries will move from /lib to /usr/lib with no harm being done.

 William


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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Rich Freeman]

On Fri, Nov 9, 2012 at 10:32 AM, William Hubbs <williamh@gentoo.org> wrote:
> That has been done already by toolchain a while back. Take a look at the
> code in toolchain-funcs.eclass. There are very few platforms where this
> function does anything at all these days. It would just be a matter of
> removing linux from the platforms it supports.

My concern isn't that the code won't do what you're expecting it to.
I have every confidence that the files will move to exactly where you
want them to go.

My concern is all the downstream effects after that.  Does anything
hard-code a path in /?  Do any config files in /etc reference those
paths, maybe for plugins/etc?  What about linking - will we have any
issues if core system binaries are linked to paths in /?

>  Since applying the patch itself will not force any rebuilds, it should
>  just end up being a natural migration; as things are rebuilt the
>  libraries will move from /lib to /usr/lib with no harm being done.

Except to anything that depends on those libraries being in /lib.
Maybe that is nothing, but until you test the migration you don't
know.

Testing doesn't mean changing the eclass, installing bzip2, and noting
that the library moves to /usr.  It means then testing anything that
depends on bzip2 and making sure that they weren't broken as a result.

Oh, and if everything doesn't move overnight then packages could
migrate in almost any order, which means you have to look out for
potential race conditions.

I would hope that the main issue is going to be linking and perhaps
@preserved-libs would help with that if it ever becomes stable.
However, when moving so many libraries you need to think carefully
about testing.  How many things depend on zlib or ncurses or libcap or
pam or libpcre?

Rich

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

On Fri, Nov 09, 2012 at 11:03:48AM -0500, Rich Freeman wrote:
> On Fri, Nov 9, 2012 at 10:32 AM, William Hubbs <williamh@gentoo.org> wrote:
> > That has been done already by toolchain a while back. Take a look at the
> > code in toolchain-funcs.eclass. There are very few platforms where this
> > function does anything at all these days. It would just be a matter of
> > removing linux from the platforms it supports.
> 
> My concern isn't that the code won't do what you're expecting it to.
> I have every confidence that the files will move to exactly where you
> want them to go.
> 
> My concern is all the downstream effects after that.  Does anything
> hard-code a path in /?  Do any config files in /etc reference those
> paths, maybe for plugins/etc?  What about linking - will we have any
> issues if core system binaries are linked to paths in /?

After separate /usr is implemented, I would throw out the patch to -dev
to disable this, then people could apply the patch and start testing;
this is when we would get all of these answers.

> >  Since applying the patch itself will not force any rebuilds, it should
> >  just end up being a natural migration; as things are rebuilt the
> >  libraries will move from /lib to /usr/lib with no harm being done.
> 
> Except to anything that depends on those libraries being in /lib.
> Maybe that is nothing, but until you test the migration you don't
> know.
 
 See above. You could apply the patch then see what breaks before we
 actually put it in the tree.

> Testing doesn't mean changing the eclass, installing bzip2, and noting
> that the library moves to /usr.  It means then testing anything that
> depends on bzip2 and making sure that they weren't broken as a result.
 
The linker script would stay in /usr/lib and the library would stay in
/lib until bzip2 was rebuilt. At that point, the library itself would move
back to /usr/lib, so wouldn't that cover linking issues?

> Oh, and if everything doesn't move overnight then packages could
> migrate in almost any order, which means you have to look out for
> potential race conditions.
 
 The only way to force everything to move overnight would be to tell
 everyone to rebuild their systems, which isn't really practical,
 because we can't make that happen.

> I would hope that the main issue is going to be linking and perhaps
> @preserved-libs would help with that if it ever becomes stable.
> However, when moving so many libraries you need to think carefully
> about testing.  How many things depend on zlib or ncurses or libcap or
> pam or libpcre?

I'm not sure how we would break linking, since the linker scripts in
/usr/lib would be replaced by the libraries only after each package is
rebuilt.

The other option could be to remove the calls to gen_usr_ldscript from
each linux-only ebuild before we disable it on linux.
That way we could see how much things break. Then, once it is out of the
linux-only ebuilds, we could disable it on linux.

I'm not sure how much that would help though since it would still hit
all of the shared ebuilds at once.

I definitely do not think that gen_usr_ldscript belongs in this council
vote; I"m not even sure it does belong in a council vote, because the
details of making this happen would be worked out on -dev.

William


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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Fabian Groffen]

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

On 09-11-2012 09:32:47 -0600, William Hubbs wrote:
> > Testing it. Testing the /usr move broadly.
> > You want gen_usr_ldscript on non-bootable systems (eg prefix, mingw) to
> > be (mostly) a noop too which you can't distinguish from only CHOST.
> 
> That has been done already by toolchain a while back. Take a look at the
> code in toolchain-funcs.eclass. There are very few platforms where this
> function does anything at all these days. It would just be a matter of
> removing linux from the platforms it supports.

They tested it?  Are you referring to the platforms from bug #417451?
(excluding the Prefix platforms, because in the Prefix tree
gen_usr_ldscript just works, because it breaks existing installs to
disable it)

> > IMHO this needs a discussion on -dev before going through the council.
>  
>  I would send the patch to do this to -dev anyway, so at that time I
>  guess we could have folks apply it and rebuild their systems and see
>  what breaks.
> 
>  Since applying the patch itself will not force any rebuilds, it should
>  just end up being a natural migration; as things are rebuilt the
>  libraries will move from /lib to /usr/lib with no harm being done.

I thought so too, until I got dangling symlinks for older zlib for some
reason (preserve-libs? ebuild?) which wasn't really a funny experience.
So, before this is done, we must test it in all forms, not rely on theory.

Alexis' profile suggestion nicely allows existing installs to remain as
is, new installs to be without /usr-split, and people to move over when
they deem that a good idea.


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Alexis Ballier]

On Fri, 9 Nov 2012 09:32:47 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Fri, Nov 09, 2012 at 08:33:55AM -0300, Alexis Ballier wrote:
> > On Thu, 8 Nov 2012 23:13:46 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> > > On Thu, Nov 08, 2012 at 08:46:29PM -0300, Alexis Ballier wrote:
> > > > On Thu, 8 Nov 2012 12:53:48 -0600
> > > > William Hubbs <williamh@gentoo.org> wrote:
> > > > 
> > > > > On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen
> > > > > wrote:
> > > > > > On 08-11-2012 11:45:48 -0600, William Hubbs wrote:
> > > > > > > >    - approve/disapprove removal of gen_usr_ldscript
> > > > > > > 
> > > > > > > A better way to put this is disabling gen_usr_ldscript on
> > > > > > > Linux. Some of the alternate platforms still use it, so I
> > > > > > > do not advocate killing the function.
> > > > > > > If we go forward with the plan, there is no reason the
> > > > > > > council should reject disabling gen_usr_ldscript on Linux
> > > > > > > that I am aware of.
> > > > > > > 
> > > > > > > This also has to wait until the blockers are resolved on
> > > > > > > the tracker.
> > > > > > 
> > > > > > Do you suggest to drop the point from the agenda?  I'd love
> > > > > > that.
> > > > >  
> > > > > I believe we can drop the gen_usr_ldscript question, yes,
> > > > > because if everything else happens, we can just have the
> > > > > toolchain guys make it a noop on Linux.
> > > > 
> > > > Something simpler and smoother imho is to just have a profile
> > > > variable that will make gen_usr_ldscript a noop, whatever CHOST
> > > > or the kernel is. New profiles are added with this variable
> > > > set, wide testing can be done without forcing anyone, and
> > > > voila. It is also simpler for maintaining the various OSes,
> > > > packages that used to install to / can just be changed to
> > > > install to /usr when this variable is set.
> > > 
> > > I'm not trying to make packages install in /usr with this change.
> > 
> > You are, since if a package in / needs a shared lib in /usr, there
> > is absolutely no point in installing the package in /.
> > nooping gen_usr_ldscript should come with a kind of plan for
> > the /usr move otherwise it is a bit ugly and somewhat loses its
> > point.
>  
> No. All of this discussion about turning off gen_usr_ldscript on linux
> applies *after* separate /usr support (either by an initramfs or with
> the busybox[sep-usr] option) is implemented.

Which is the only viable solution, I agree.

> Once one of these options
> is implemented, /usr is always available when / is, so the "barrier"
> between / and /usr no longer exists. That just means you don't need
> to move shared libraries to / for binaries in / to link to them. It
> is the same as if you didn't put /usr on its own partition. To me,
> your argument here about disabling gen_usr_ldscript is like saying,
> if you put / and /usr on the same partition you should do a /usr move.

Then why would you put anything in /, besides static binaries, after all
this ? This is exactly what happened to udev & friends: after tons of
"""harmless""" additions that required /usr to be mounted, it has been
decided that separate /usr isn't going to work anymore. You're only
missing the last step: move it to /usr and at least have some benefits
instead of artificially maintaining a non-working /usr barrier for
historical reasons.

Again, what is the point of having a binary in /bin that links to a
library in /usr ?

> > > gen_usr_ldscript was introduced to force shaired libraries that
> > > upstream installs into /usr/lib to move to /lib and leave the
> > > static libraries in /usr/lib.
> > 
> > It's rather the opposite actually: very few upstream specify their
> > install location, most default to /usr/local prefix because that's
> > autotools default. econf (ie us) sets the prefix to /usr.
> > gen_usr_ldscript is there because we don't need the static lib in /
> > (so that setting libdir to /lib is not an option) while the shared
> > lib is needed by binaries in /. We could just move the shared lib
> > to / but then the linker may link to the static lib if /usr/lib
> > comes before /lib in its search order, so we need a .so in the same
> > dir as the .a. For example FreeBSD solved that differently: they
> > symlink /lib/libfoo.so to /usr/lib/libfoo.so. Years ago we deemed
> > symlinks crossing the /usr barrier were bad, and here comes
> > gen_usr_ldscript. Note that I don't really see the difference
> > between a symlink crossing the /usr barrier and a ldscript
> > referencing a file outside of /usr but there must be some argument
> > behind.
> 
> I spoke to flameeyes about symlinks crossing the /usr barrier, wrt
> another package, and he doesn't have a problem with this. I also have
> never seen any policy etc deaming them bad, but that's another
> discussion.

Well, last time I tried this, portage threw out big fat warnings for
such symlinks iirc. I'd call that policy :)

> All I'm saying is that implementing separate /usr support on linux
> eliminates the /->/usr barrier since / and /usr are always available
> at the same time, thus eliminating the need for gen_usr_ldscript.

Agreed, and also eliminating the need for separating /bin and /usr/bin

> > Let's move everything to /usr/local :) there is not really a 'where
> > upstream installs them' argument in this discussion, autotools is
> > specifically designed so that distributions can tweak the install
> > location. The fact that both the static and shared libs go to
> > libdir is only a shortcoming of autotools, some other build systems
> > make the distinction.
>  
> I'm not familiar with many other build systems, so I can't really
> comment specifically to this. But, I wonder why you would need to
> separate where static and shared libs are installed.

Because sometimes you need to call gen_usr_ldscript :)

> > > Since we can tell we are on linux by looking at the chost/ctarget
> > > variables, and there is not an intention to change anything for
> > > *bsd or any other O/S, I am not sure I follow the need for a
> > > profile variable.
> > 
> > Testing it. Testing the /usr move broadly.
> > You want gen_usr_ldscript on non-bootable systems (eg prefix,
> > mingw) to be (mostly) a noop too which you can't distinguish from
> > only CHOST.
> 
> That has been done already by toolchain a while back. Take a look at
> the code in toolchain-funcs.eclass. There are very few platforms
> where this function does anything at all these days. It would just be
> a matter of removing linux from the platforms it supports.

Yeah, I remember that, and also when it completely broke freebsd-lib.
Maybe that's the reason why I'm reluctant to hardcoding this :)

[...]

> > > If they want to discuss the gen_usr_ldscript issue I'm not
> > > opposed to that, but that isn't really what I am asking for in
> > > this meeting.
> > 
> > IMHO this needs a discussion on -dev before going through the
> > council.
>  
>  I would send the patch to do this to -dev anyway, so at that time I
>  guess we could have folks apply it and rebuild their systems and see
>  what breaks.
> 
>  Since applying the patch itself will not force any rebuilds, it
> should just end up being a natural migration; as things are rebuilt
> the libraries will move from /lib to /usr/lib with no harm being done.

If you stop there then all what you get is an artificial /usr and /
separation. According to Fedora, you gain much more with the /usr move
than the few bytes you save without ldscript. Please give me a reason
not to do an /usr move once you have covered all the needs to make it
possible.

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

On Fri, Nov 09, 2012 at 07:21:25PM +0100, Fabian Groffen wrote:
> On 09-11-2012 09:32:47 -0600, William Hubbs wrote:
> > > Testing it. Testing the /usr move broadly.
> > > You want gen_usr_ldscript on non-bootable systems (eg prefix, mingw) to
> > > be (mostly) a noop too which you can't distinguish from only CHOST.
> > 
> > That has been done already by toolchain a while back. Take a look at the
> > code in toolchain-funcs.eclass. There are very few platforms where this
> > function does anything at all these days. It would just be a matter of
> > removing linux from the platforms it supports.
> 
> They tested it?  Are you referring to the platforms from bug #417451?
> (excluding the Prefix platforms, because in the Prefix tree
> gen_usr_ldscript just works, because it breaks existing installs to
> disable it)

Look at the first case statement in gen_usr_ldscript and tell me if you
disagree with what I'm saying. The function always executes on darwin.
On linux and any bsds, it executes for non-prefix setups. On any other
platform, prefix or not, it does nothing.
 
So, if I'm reading the code correctly, on prefix, more than likely it
isn't doing anything.

> > > IMHO this needs a discussion on -dev before going through the council.
> >  
> >  I would send the patch to do this to -dev anyway, so at that time I
> >  guess we could have folks apply it and rebuild their systems and see
> >  what breaks.
> > 
> >  Since applying the patch itself will not force any rebuilds, it should
> >  just end up being a natural migration; as things are rebuilt the
> >  libraries will move from /lib to /usr/lib with no harm being done.
> 
> I thought so too, until I got dangling symlinks for older zlib for some
> reason (preserve-libs? ebuild?) which wasn't really a funny experience.

What symlinks did you have?

> So, before this is done, we must test it in all forms, not rely on theory.
 
I am not disagreeing with you.

The only way to test is, after the time window for migrating to
initramfs or sep-usr busybox expires, have people start migrating and
see how it goes.

> Alexis' profile suggestion nicely allows existing installs to remain as
> is, new installs to be without /usr-split, and people to move over when
> they deem that a good idea.

If we do this with a variable, I suggest using it temporarily, but
ultimately dropping it and having everyone switch over after things are tested.

Again, I think 6 months or a year are too long for this testing window.

William


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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Fabian Groffen]

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

On 09-11-2012 19:42:06 -0600, William Hubbs wrote:
> > They tested it?  Are you referring to the platforms from bug #417451?
> > (excluding the Prefix platforms, because in the Prefix tree
> > gen_usr_ldscript just works, because it breaks existing installs to
> > disable it)
> 
> Look at the first case statement in gen_usr_ldscript and tell me if you
> disagree with what I'm saying. The function always executes on darwin.
> On linux and any bsds, it executes for non-prefix setups. On any other
> platform, prefix or not, it does nothing.
>  
> So, if I'm reading the code correctly, on prefix, more than likely it
> isn't doing anything.

Oh my, I made an error in the logic!  Thanks for pointing out!

> > I thought so too, until I got dangling symlinks for older zlib for some
> > reason (preserve-libs? ebuild?) which wasn't really a funny experience.
> 
> What symlinks did you have?

lib/libz.so.1 -> libz.so.1.2.5
(I upgraded 1.2.5 to 1.2.7)

> If we do this with a variable, I suggest using it temporarily, but
> ultimately dropping it and having everyone switch over after things are tested.

We know that FreeBSD will never (for how it looks now) follow, so we
need to keep the code anyway.  Since it breaks e.g. Darwin, I'd like not
to disappoint my users by saying: "sorry, you'll have to reinstall".
Last but not least, I see no reason (given we have to keep the code
anyway) to make sysadmins, that feel unsure about this on their running
production systems, go into this route.  You don't know what custom code
they have installed/running.  They'll be on their own (no
udev/GNOME/whatever support), but most likely they won't care about that
at all.


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs]

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

On Sat, Nov 10, 2012 at 10:00:33AM +0100, Fabian Groffen wrote:
> On 09-11-2012 19:42:06 -0600, William Hubbs wrote:
> > > I thought so too, until I got dangling symlinks for older zlib for some
> > > reason (preserve-libs? ebuild?) which wasn't really a funny experience.
> > 
> > What symlinks did you have?
> 
> lib/libz.so.1 -> libz.so.1.2.5
> (I upgraded 1.2.5 to 1.2.7)

Looking at the code further in gen_usr_ldscript, it only uses symlinks
in one case, and that is in darwin, because their linker doesn't
understand nlinker scripts. It puts a symlink in /usr/lib* that points
to the library in /lib/* instead of a linker script.

> > If we do this with a variable, I suggest using it temporarily, but
> > ultimately dropping it and having everyone switch over after things are tested.
> 
> We know that FreeBSD will never (for how it looks now) follow, so we
> need to keep the code anyway.  Since it breaks e.g. Darwin, I'd like not
> to disappoint my users by saying: "sorry, you'll have to reinstall".

The *bsds and Darwin are not what I'm discussing; of course we have to
keep the code for them. I'm not disagreeing with you here either. The
change I'm talking about will not affect alternate platforms. :-)

The change I'm talking about, again after giving linux users a window to
migrate to initramfs or busybox[sep-usr], would be to remove the
'*linux*|' from line 623 of toolchain-funcs.eclass, or if we need
another variable for this, add something else to that branch of the 
the case statement for a while and remove the '*linux*|' and the new
code later.

Given that, I don't understand why you are thinking you will have to
tell your users that they will have to reinstall. Reinstalllation is not
part of this.

> Last but not least, I see no reason (given we have to keep the code
> anyway) to make sysadmins, that feel unsure about this on their running
> production systems, go into this route.  You don't know what custom code
> they have installed/running.  They'll be on their own (no
> udev/GNOME/whatever support), but most likely they won't care about that
> at all.

No, we don't know what custom code people are running, but custom
someone is running is not an excuse to block change. We just
have to make change happen in an orderly fashion and make sure people
are aware of the change so they can find ways on their end to adapt.
Isn't that reasonable?

William


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

Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Ian Stakenvicius]

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

By the way -- I assume everyone is aware that the council meeting is
taking places on Tuesday, November 13th (and not the 11th), right?

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

iF4EAREIAAYFAlCerVkACgkQ2ugaI38ACPDfBAEAt0NSdayi8w+MsdJ6ZE9gv264
6LFYkIY6A2R96+CR2z4BAIDv6TnbLOXHYDADhcZkFqKWn/Tq/RyrOGqDe85cFxVs
=spcv
-----END PGP SIGNATURE-----

Re: [gentoo-project] Council meeting: Tuesday 13 November 2012, 19:00 UTC

[Petteri Räty]

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

On 10.11.2012 21:39, Ian Stakenvicius wrote:
> By the way -- I assume everyone is aware that the council meeting is
> taking places on Tuesday, November 13th (and not the 11th), right?
> 
> 

Yeah you are correct. Tuesday is when they usually are. I swapped the
subject as well :)

Regards,
Petteri


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

Re: [gentoo-project] Council meeting: Tuesday 13 November 2012, 19:00 UTC

[Fabian Groffen]

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

On 10-11-2012 13:37:48 -0600, William Hubbs wrote:
> > Last but not least, I see no reason (given we have to keep the code
> > anyway) to make sysadmins, that feel unsure about this on their running
> > production systems, go into this route.  You don't know what custom code
> > they have installed/running.  They'll be on their own (no
> > udev/GNOME/whatever support), but most likely they won't care about that
> > at all.
> 
> No, we don't know what custom code people are running, but custom
> someone is running is not an excuse to block change. We just
> have to make change happen in an orderly fashion and make sure people
> are aware of the change so they can find ways on their end to adapt.
> Isn't that reasonable?

I look at it from the other side, why do we have to make upgrading
impossible for people that can not, or will not perform that change?
In the end, most packages are completely unrelated to the change we are
going to demand from our users here.


-- 
Fabian Groffen
Gentoo on a different level

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

[gentoo-project] [corrected date] Council meeting: Tuesday 13 November 2012, 19:00 UTC

[Fabian Groffen]

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

On 06-11-2012 22:28:16 +0100, Fabian Groffen wrote:
> The next council meeting will be on Tuesday 11 November 2012 at 19:00 UTC
> in the #gentoo-council channel on Freenode.

This is a mistake.  The meeting will be on Tuesday 13 November 2012.
I'm sorry for the confusion.

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 11 November 2012, 19:00 UTC

[Ulrich Mueller]

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

graaff will be my proxy.

Ulrich

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

Re: [gentoo-project] Council meeting: Tuesday 13 November 2012, 19:00 UTC

[William Hubbs]

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

On Sun, Nov 11, 2012 at 09:51:36AM +0100, Fabian Groffen wrote:
> On 10-11-2012 13:37:48 -0600, William Hubbs wrote:
> > > Last but not least, I see no reason (given we have to keep the code
> > > anyway) to make sysadmins, that feel unsure about this on their running
> > > production systems, go into this route.  You don't know what custom code
> > > they have installed/running.  They'll be on their own (no
> > > udev/GNOME/whatever support), but most likely they won't care about that
> > > at all.
> > 
> > No, we don't know what custom code people are running, but custom
> > someone is running is not an excuse to block change. We just
> > have to make change happen in an orderly fashion and make sure people
> > are aware of the change so they can find ways on their end to adapt.
> > Isn't that reasonable?
> 
> I look at it from the other side, why do we have to make upgrading
> impossible for people that can not, or will not perform that change?

If there are people running gentoo Linux who CAN NOT do this, they
definitely should speak up. That's exactly why a newsitem needs to be
sent out announcing this and giving a time window before we go forward
with anything.

There is a difference between CAN not and WILL not. If you disagree with
what I'm about to say say so, but it seems to me that if someone WILL
not perform a change, that is more something they should worry about,
not us.

William


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

[gentoo-project] Summary Council meeting Tuesday 13 November 2012

[Fabian Groffen]

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

Summary of Gentoo council meeting 13 November 2012


Roll Call
=========
betelgeuse
Chainsaw
rich0 (proxy for dberkholz)
graaff (proxy for ulm)
grobian
scarabeus
WilliamH


Handling separate /usr support
==============================
WilliamH requested approval for two methods to support separate /usr
systems[2].  The discussion is closely related to recent opinons on udev, such
as e.g. [1], because the main reason to force a system without separate /usr
during boot is to allow newer versions of udev to be used.
The originally announced item of discussing the removal of gen_usr_ldscript
has been retracted[4].
- approve/disapprove plan (forcing everyone to take action, and
  implement one of the two "supported" solutions)

WilliamH requests a council vote to allow migrating everyone after bugs
[5,6,7] are resolved.  He proposes a news item to announce this that allows to
assume after a given period of time that everyone who is using split /usr is
using a method to mount /usr before boot.  The focus is purely on this topic.

rich0 prefers to move on until suport for separate /usr becomes a
barrier, and handle things from there.  This allows for alternative
solutions to be developed and put forward.  He favours waiting somewhat
to see developments of the udev fork.

Chainsaw is a strong proponent for waiting a month and see how the new
udev fork develops itself.  If within a month no solution is provided by
the udev fork, things need to be moved forward in WilliamH's proposed
way.

scarabeus approves the plan.

betelgeuse likes to ensure users won't be caught off guard, but has no
preference for any direction taken in particular.

graaff's main concern is how the problem is tied to udev, or not.  A fork of
udev may not change the situation regarding separate /usr, hence delaying a
decision now is not sensical.  Opt-in system for people to ensure they can
boot is pre-requisite.  If this cannot be ensured, we have to wait.

grobian disapproves the plan, since there will be systems that cannot easily
be changed to ensure /usr being mounted at boot, and it is no good to expel
users of (security) updates just because of that.  With the use of a special
profile (masks/unmasks, variables and/or use-flags), users that want to move
on, can opt-in to getting packages that require non separate /usr.



Policy on "<" versioned dependencies
====================================
chithahn requested the council to clear up confusion around "<" versioned
dependencies[3].  This issue seems to combine:
1) notorious behaviour from the usual suspects
2) QA policies whether or not they are properly documented/advertised
3) the technical problem of "<" dependencies causing downgrades

The council sees no rule that makes it illegal to use < dependencies, but
strongly discourages their use.  It must be noted that for some
packages, a downgrade is very undesirable.  This has triggered package
removals in the past.  However, the council requests the teams responsible for
that removal to act reasonably and in good cooperation with the maintainers of
the packages in question.


Open bugs with council involvement
==================================
Bug 383467 "Council webpage lacks results for 2010 and 2011 elections"
- ulm has done the work here, waiting for a confirmation that we can really
  close the bug
Bug 438338 "Please update devmanual with EAPI5 info"
- no progress and/or actions planned for this


Open Floor
==========
No issues were brought up to the council.


Next meeting date
=================
11 December 2012, 20:00 UTC


[1] https://lkml.org/lkml/2012/10/2/303
[2] http://thread.gmane.org/gmane.linux.gentoo.project/2208
[3] http://thread.gmane.org/gmane.linux.gentoo.project/2213
[4] http://article.gmane.org/gmane.linux.gentoo.project/2235
[5] https://bugs.gentoo.org/411627
[6] https://bugs.gentoo.org/435756
[7] https://bugs.gentoo.org/441004


-- 
Fabian Groffen
Gentoo on a different level

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