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

[William Hubbs <williamh@gentoo.org>]

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