> 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
signature.asc
Description: This is a digitally signed message part
