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

[William Hubbs]

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@g.o> 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