From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E1rWo-0001pe-FJ for garchives@archives.gentoo.org; Sun, 07 Aug 2005 20:13:51 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j77KCMIA016614; Sun, 7 Aug 2005 20:12:22 GMT Received: from buggy.blubb.ch (range21-65.shlink.ch [217.148.7.65]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j77KCMcU016220 for ; Sun, 7 Aug 2005 20:12:22 GMT Received: from aqua ([192.168.10.5]) by buggy.blubb.ch with esmtp (Exim 4.50) id 1E1rVO-00081M-3X for gentoo-amd64@lists.gentoo.org; Sun, 07 Aug 2005 22:12:22 +0200 Message-ID: <42F66B78.1030708@gentoo.org> Date: Sun, 07 Aug 2005 22:13:44 +0200 From: Simon Stelling User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: file type not allowed in /usr/lib References: <42F53B6D.1080908@burnieanglican.org.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 3b6a696c-adf6-475e-a854-09f7051f8b54 X-Archives-Hash: 02b7e442cd6cf62a21e5128d3e736fdb 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@gentoo.org -- gentoo-amd64@gentoo.org mailing list