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

[Simon Stelling]

Hi,

Duncan wrote:
> I'm repeating what Simon said, but sometimes it helps to get it said a
[snip]
> The immediate user-level fix, as Simon says, is kill the
[snip]
> Here's the background.  As Simon explained, in ordered to be able to have

Just a personal note on this: What's the point in repeating everything? 
You only bore people with it. I think we can assume that the original 
poster either gets it the first time, or he'll surely ask again and give 
details about what he didn't understand.

> First, there's the binary compatibility issue, both with legacy apps and
> moving forward.  It's simply harder to get binaries from other sources to
> work, when they are designed with one set of assumptions about locations,
> but installed on a system with a rather different set of assumptions.  As
> I said, there's the 32-bit legacy thing, but consider continuing effect
> going forward, as well.  If we stayed the way we are, every binary-only
> installation a Gentoo-amd64 user ever made, including the new amd64
> binaries, when they become common, would be a fight. Despite the temporary

Why? When the binary gets linked, ldd just looks into various places and 
decides which library to take depending on the bitness. There's no 
fight, there's /etc/ld.so.conf. Sorry, but that paragraph is fubar.

> mostly duplicated common code, it's ALWAYS more efficient to keep in line
> with the rest of the community, so the maintenance and further development

I disagree: There are bad standards, which should be replaced by better 
ones. You can't do that by keeping in line with the rest.

> Thus, the upstream compatibility issue resolves to this:  the closer we
> are to accepted LSB/FHS standard, the less work we will have to do making
> changes so that open source packages which generally target the loose

Wrong. Correct would be: the closer we are to UPSTREAM, the less work we 
will have to do. A nice example: QT

> Together, these two reasons means the only /possible/ sensible alternative
> is to bite that bullet, and exchange some temporary misery now, while the
> conversion is in progress, for a /far/ more standards compliant multilib
> setup, going forward.

What misery?

> Currently, Gentoo-amd64 has just about finished moving 64-bit libs out of
> lib.  We have both a lib32, and a lib64, with lib being a symlink to
> lib64, for those remaining packages (such as skencil, apparently) that
> have so far fallen thru the cracks, and continue to make the early
> Gentoo-amd64 assumption that lib is the 64-bit shared object location.
> 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.  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.  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.
> 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.)

Where do you get this information from? We (read: we, the Gentoo/AMD64 
developer team) never published such a roadmap, nor do we have one 
ourselves. Please, don't cook up a story just to enlarge your 
pen^W^W^Wmails.

> 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, since the new portage
> remains only in CVS, there hasn't yet been even the usual hard masked for
> testing alpha snapshot releases, let alone the -preX versions, which would
> be the first ones that could even theoretically leave hard mask testing,
> for ~arch testing.  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.  Until then,
> Gentoo-amd64 32-bit support will remain spotty at best, requiring users
> either install from tarball, or use a 32-bit chroot with its own portage
> tracking 32-bit dependencies, for pretty much anything beyond the core
> system libraries (sandbox, gcc, glibc, now from-source supported, other
> 32-bit core libraries managed as binary-only packages or from the chroot).

You can take comfort with the fact that even if portage already had this 
functionality, there wouldn't be real multilib now.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@g.o
-- 
gentoo-amd64@g.o mailing list