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 1E2DD2-0003EU-Nn for garchives@archives.gentoo.org; Mon, 08 Aug 2005 19:22:53 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j78JJvib000161; Mon, 8 Aug 2005 19:19:57 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 j78JJuN8001029 for ; Mon, 8 Aug 2005 19:19:56 GMT Received: from aqua ([192.168.10.5]) by buggy.blubb.ch with esmtp (Exim 4.50) id 1E2DAJ-00013K-Ei for gentoo-amd64@lists.gentoo.org; Mon, 08 Aug 2005 21:20:03 +0200 Message-ID: <42F7B071.7060603@gentoo.org> Date: Mon, 08 Aug 2005 21:20:17 +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: Re: file type not allowed in /usr/lib References: <42F53B6D.1080908@burnieanglican.org.au> <42F66B78.1030708@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 7dd178bd-1727-48f4-b059-198a00ef2b2d X-Archives-Hash: 8d752e34f56a1d7a545ccd19a00215c1 Hi, Duncan wrote: >>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. > > > OK, first, the tone here and below seems to indicate I offended you in > some way. Let me unconditionally state at the outset, that such was in no > way the intent. It appears you took my post as somehow implying yours > was incomplete or inadequate in some way. Again, that couldn't have been > farther from my intentions! I intended to credit you where appropriate, > acknowledging the overlap in ideas, but would have posted whether you had > or not, because I had some of my own ideas to express, in my own reply, as > is customary on public lists and newsgroups. I evidently came across in a > way I never intended at all, and for that I unconditionally apologize. First, I didn't really want to offend you, although I have to admit that a few statements were rather harsh. I didn't feel offended, and I know you didn't want to say my answer was incompetent. However, if I *were* the questioner, I'd feel offended, since I don't need everything explained twice, and if I don't get it, I ask further questions. Generally explaining it a second time somehow implies that I didn't get it the first time, but perhaps that's just me. > Not necessarily. You are correct about dynamic linking, but what about > binary only installers? These may be hard coded to a specific > path, certainly by default, tho it's usually possible to change it if > necessary. Even if it's changeable on the command line, or from a script, > or even if it's open source, making and maintaining that change thru > multiple versions over time is certainly more difficult than never having > to make it in the first place, because our default happens to be the > standard default. If it's prepackaged as an ebuild, that's work the > Gentoo developers have to do (or not, if the defaults coincide). If it's > something a Gentoo user is installing on their own, not from an ebuild, > then having to fiddle with installer configs to get it to go to the right > place is "a fight" that /could/ be avoided, if we were using the defaults > in the first place. Judging from my experience, the opposite is the case: Most of the hardcoded programs just install to /usr/lib without bothering about their bitness, so it'd be better to set lib = 64bit as a longterm-solution, assuming that amd64 will (at least partly) replace x86. Also, most of the "hardcoded programs" aren't closed source but open source apps. Also, once these hardcoded paths are made suitable, it's quite easy to do the same with the next version: Just bump the ebuild. There are *very* few configure scripts which try to find out the correct place for libraries theirselves, and in most of these very few cases, they're broken anyway, as the just grep uname -a for Athlon64 or Opteron, which then would break 32bit. >>>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. > > > That doesn't alter the truth of the point I made. It's ALWAYS more > efficient (that is, less work) to keep in line with the rest of the > community. That does NOT always mean it's BETTER, only that it's MORE > EFFICIENT. The point I made was that this factor serves as a unifier > within the community, always ensuring that distributions diverge only on > the points they consider IMPORTANT, where the extra work is therefore > worth it, as opposed to any old thing not considered so important, in > which case it makes the most sense to go with the community standard, > since that's less work, and the extra work necessary to deviate isn't > considered worth it, since it's "not important". 'more efficient' is a synonym to 'better', for me, as I consider efficiency a 'good' thing. If you mean it's more comfortable, you're right, but then this questions pops up: Do we want to make good applications, or comfortable ones? (Comfortable to the developer, not the user of course.) > required to maintain that change. It doesn't pay to be different just to > be different. Because there's an unavoidable cost involved with being > different, do it where it's worth the trouble, don't do it where it's not. Sure, if that's the point you made, I absolutely agree, I just don't think such a self-evident statement is even worth to mention, so I thought you wanted to state something different. > As a matter of fact, this does interest me (as should be pretty obvious > by now ). Do you have any evidence of an opposing trend, AWAY from the > LSB/FHS standard, or toward no accepted common standard, in this instance? > To date, everything I've read seems to indicate the trend, possibly slow, > but there none-the-less, is /toward/ the LSB/FHS multilib standard, at > least in the case of amd64. If there's evidence to the contrary, please > do point me to it! I'd much rather find out and have to admit I'm wrong > now, and have the truth as my guide in the future, than otherwise. I > simply haven't yet seen anything that would invalidate my previous > assumption, and certainly what the pro-LSB press would have one believe. I can't see neither a movement toward LSB/FHS nor away from it. I think such standards are generally usefull as they make programming a lot easier, but in the end, each user should receive the power to decide where which type of file goes. So the ultimate goal shouldn't be to adore a certain standard but to make the tool as flexible as possible, e.g. by providing Makefiles where you just can reset LIBDIR if you don't the default. If every tool would be that flexible, we wouldn't need to bother about FH standards at all. >>What misery? > > > That of those who found the 2004.3 -> 2005.0 upgrade rather more painful > than they would have liked? That of those that ended up formatting and > reinstalling Gentoo, not entirely a pain free process, because they were > stuck with a half-upgraded system that would no longer work right on > /either/ the 2004.3 /or/ the 2005.0 profile? That of those that chose to > avoid the issue for the time being and are staying on 2004.3, due to the > horror stories as posted here and in the forums, from those faced with the > situation above? That's a misery indeed, however, that's not related to the lib/lib64/lib32 change. As you can see in the new development guide [1], the situation is basically the same in 2004.3 and 2005.0. The major change which causes problems for many users is that in 2005.0, multilib is enabled by default, while on 2004.3 it's not, and to get a multilib-capable system, you need a multilib-capable toolchain (well, not the whole toolchain, otherwise it'd be impossible without using binpkgs). Anyway, the issues caused with the upgrade to 2005.0 would be the same if the lib/lib64/lib32 scheme would be the same as in 2004.3. >>>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. > > > OK, it's quite apparent you have a personal problem with my style, and > possibly with the fact that I paralleled your post, tho I really don't > know why that should be a problem at all. Perhaps that part should be > taken to private mail, if you wish to continue the discussion. Not at all. The "enlarge your pen^W" shouldn't offend you, it was meant as a joke, critisizing the massive amount of spam we all get with this topic, not you :D Sorry if it looked like a diparaging remark, that really wasn't my intention. > The key is, it's my speculation, and the phrasing I chose /should/ have > made that quite apparent. [snip] > The fact > remains, however, I was writing what "I expect", what I consider > "possible", or even likely, and labeled it as exactly that. I certainly > did **NOT** label it as any sort of official road map, quite the contrary! It rather looked like an official roadmap coming from a dev to me, but in that case, I just got it completely wrong. I apologize. > Assuming that we agree on the current status, and that nothing has changed > from previous plans (and of course that I understood said plans > correctly), what's the next reasonable step in the process? Before we > break that lib -> lib64 link, isn't it reasonable to go stable with the > multilib-strict warning, to flush anything out that was missed by those > deliberately testing? I know I'd rather file a bug about a warning and > failed emerge as a result, with my previous version continuing to function > normally, than I would file a bug because the link was broken and I now > have currently merged programs that no longer work! What you stated above was correct, but given the fact that many users think much of you, i find it risky to issue a complete roadmap with more or less precise dates for each step. The main problem I saw here were users coming to us in 2007 and asking why the hell we didn't finish the whole thing. > The rest of the steps follow, one at a time. Unless I'm seriously > mistaken, or unless things have changed, we'll follow the general outline, > tho the timing could easily be off, and the individual steps may be > somewhat different. In any case, even if I AM seriously mistaken, it was > labeled "my expectation", not "official Gentoo roadmap", and who am I, > that someone should trust my predictions over that of Joe Blow? It's not > as if I'm posting with an @gentoo.org email address or something. Just > like the speculations of any other Joe Blow, if they find my speculations Well, your not just a random guy like Joe Blow, you're a much appreciated user with a lot of knowledge, and that gives you power as well as responsibility. >>>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. >> >>You can take comfort with the fact that even if portage already had this >>functionality, there wouldn't be real multilib now. > > Somewhat of an enigmatic comment. There are a number of ways it could be > taken. > > If "now" is taken to mean "as opposed to previous plans", it /could/ mean > that Gentoo in general, and Gentoo-amd64 in particular, has put on hold > further advances toward multilib, and may in fact reverse course. Luckily > for me, the only 32-bit stuff I run is the stuff in the 2005.0 normal > profile (along with LILO), since I believe in FLOSS strongly enough to be > uninterested in closed source, even 32-bit only proprietary codecs and > plugins, and open source means 64-bit portable and for my purposes, that > means pretty much already ported. Thus, personally, 32-bit and therefore > multilib, is more a hassle than anything, meaning double the time > compiling glibc, for instance. However, I certainly empathize with those > who have 32-bit stuff they still want/need to run. (If this is the way > "now" is to be read, the tone of the comment could also imply a bit of > bitterness, that this decision was made, as well. That's not a given, as > it could imply satisfaction at the result, instead, or simply nothing. > Again, enigmantic...) Heh, that really made me laugh. We're not going back, everything is going on as planned. The problem I had in mind when writing the above statement is following: Let's say we have appfoo (yes, again :D), which needs various X11-libraries, as it has a GUI. We want appfoo to be compiled 32bit, but the huge majority is 64bit, and of course xorg-x11 is 64bit too. Now, where we want to install appfoo as a 32bit binary with the portage able to track 32bit dependencies, it will install xorg-x11 32bit, because we need the libraries in that packages 32bit. But then, the install routine would overwrite the xorg binary and we'd end up with a 32bit xorg, which we don't want. To solve this issue, we have the following options: a) Split up libraries and binaries into seperate packages. This is what currently happens to X, thanks to spyderous. See eradicator's thoughts on this [2]. b) Implement a filter to just install the shared objects. This has the advantage that we don't have to split up a huge amount of packages and keep closer to upstream, which is generally a good idea. However, there are still unresolved issues: Portage would need another addition, something like a 'only libs' flag, and personally, I don't like that idea so much, as it looks a bit untidy. Also, you need e.g. headers the first time you install a certain library, so things are getting complicated. In addition, there is still the unresolved issue about the -config scripts in /usr/bin, which would get overwritten everytime you install the same lib with another bitness. Unfortunately we can't just copy a solution from another (binary-based) distro, as they don't have this problem. Also, the universally beloved FHS doesn't give us an answer to this problem. A really easy solution would be to just create /usr/bin64, similiar to /usr/lib and /usr/lib64, but we all know this would lead to a massive amount of time-consuming work, and as you said in your original mail, it's simply not worth the effort. Of course it wouldn't be a problem at all if all applications would have a more flexible build system, as I stated above. All in all, I'm sure we will have a fully multilib-capable system in the end, but I'm rather pessimistic about the time schedule. I'll better finish now, this mail got much longer than I wanted it to be, and I hope I don't bore the readers ;) Kindly regards, Simon [1] http://dev.gentoo.org/~plasmaroo/devmanual/archs/amd64/#libdir-links [2] http://ramblings.hudscabin.com/blogs/index.php/2005/05/02/multilib_and_toolchain_thoughts -- Simon Stelling Gentoo/AMD64 Operational Co-Lead blubb@gentoo.org -- gentoo-amd64@gentoo.org mailing list