Re: [gentoo-amd64] Re: file type not allowed in /usr/lib

[Jeremy Huddleston]

> With 2005.1, I'm expecting FEATURES=multilib-strict will be the default,
> to finally weed out as many of the few remaining back packages as
> possible.

I don't suspect that will be "default" as I'd rather not burden users
with those problems that should be caught by developers.  Before we make
the switch to eliminating the symlink for good, we'll need to QA every
amd64 marked package to make sure it doesn't break under
multilib-strict... I'm not looking forward to that, but hopefully we'll
be able to break up the burden among the devs, ATs and community.

> With 2006.0, it's possible that lib -> lib64 symlink can
> finally be broken, and any remaining packages then WILL get bugs filed,
> when someone tries to use them and has issues.

You can actually do that now with the 2005.0/no-symlinks profile, but I
haven't done much QA on it yet, but PLEASE file bugs that you come
across with it.

> With luck, by 2006.1, it
> should be safe to start doing basically the same thing with the lib32 ->
> lib move, as we will have just got thru doing with the lib -> lib64 move.

Again, 2005.0/no-symlinks/no-lib32 profile... uh... don't expect this
one to work though ;)  BUG reports welcome... also developer muscle
welcome.  I want to get gcc-config 2.0 done first (see my blog).

> First, there will be a symlink between the two, in another release or two,
> the main packages will be changed and it'll be time to activate the
> multilib-strict test for anything still ending up in lib32 instead of lib.
> By 2007.0, therefore, if luck holds, that multilib-strict test can be the
> default, to catch all the stragglers possible, and 2007.1 should then
> hopefully be able to remove lib32, relegating it to the annuls of
> Gentoo-amd64 history.  (Those .1 mentions assume that Gentoo continues
> with the twice-yearly releases, thus, they mean second-half.)

So yeah, in like many years down the road, this should all be worked out
assuming I get off my ass and get things rolling...

> However, that's really only half the issue.  The other half is portage,
> which currently can't track 32-bit dependencies separate from its 64-bit
> dependencies.  We had hoped that portage would have dual-bitness support
> by 2005.1, but that's now looking impossible,

Uhm... yeah... did I mention that I don't like python... so that means
this probably won't happen soon or quickly unless someone else steps up
to the task to help out (or someone convinces me to enjoy python)...
the design is pretty much there, but it's not gonna get implemented by
me alone.  If anyone is interested in helping out with this project,
this is a great opportunity to contribute a much needed feature.

> Thus, it'll be 2006.0 at the earliest, before portage
> will be able to handle dual-bitness tracking, keeping the 32-bit
> dependencies separate from the 64-bit dependencies.

And that's very optimistic.

--Jeremy