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 1E29po-0003lE-7Q for garchives@archives.gentoo.org; Mon, 08 Aug 2005 15:46:41 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j78Fixab027992; Mon, 8 Aug 2005 15:44:59 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j78Fix3T028094 for ; Mon, 8 Aug 2005 15:44:59 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E29m2-0003kD-C1 for gentoo-amd64@lists.gentoo.org; Mon, 08 Aug 2005 17:42:46 +0200 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Aug 2005 17:42:46 +0200 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Aug 2005 17:42:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Re: file type not allowed in /usr/lib Date: Mon, 08 Aug 2005 08:40:52 -0700 Organization: Sometimes Message-ID: References: <42F53B6D.1080908@burnieanglican.org.au> <42F66B78.1030708@gentoo.org> 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: a0adbfcb-f1af-4274-8531-5ddf882b4674 X-Archives-Hash: 59502021729a361a1d9ce8995aa85f11 Simon Stelling posted <42F66B78.1030708@gentoo.org>, excerpted below, on Sun, 07 Aug 2005 22:13:44 +0200: > Hi, > > Duncan wrote: >> I'm repeating what Simon said, but sometimes it helps to get it said a > [snip] > > 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. The following, therefore, is simply replying to your question, explaining (again, I /did/ mention it in the original post) why I did repeat some of what you had already covered. Not just repeating, but saying it in different words. As I explained and as educators well know, reading something said in two different ways at minimum reinforces the concept, and will in many cases allow someone to grasp a concept put in different terms, where they couldn't get it as it was stated the first time. I'm sure some find your version easier to understand, and as a dev, it's closer to the horse's mouth in terms of official policy, certainly. However, I /know/ from being directly told so any number of times, that for whatever reason, many find my explanations of a concept easier to understand than all the explanations they may have read before. Anyway, if I'm boring people, there are always the filters, if they ultimately find my opinion so objectionable that simply skipping over it isn't enough. I know others find my posts useful, because they've said as much. >> 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. 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. >> 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". By definition, if it's a "bad" standard, it's important enough to make a difference, to be /worth/ the extra work involved in diverging from that standard. Thus, I agree with you, in that there ARE valid reasons to disagree with a standard, to go your (our) own way. I'm only saying that doing so unavoidably incurs an additional cost in terms of resources 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. Thus, there are dual but opposing forces, normally keeping each other in balance, the force leading to differentiation from the competition, on the one hand, with the avoidable cost of that differentiation on the other, ensuring that it's /only/ done where the benefits are judged to be worth more than the costs. This is one of the strengths of open source, and the most common reason pointed to when someone asks what's keeping us together, as contrasted with the fragmentation of proprietary Unix. Because they were proprietary, each implementation had to bear far more of its own weight -- they couldn't (chose not to) share implementation and support details, so the forces of divergence were NOT balanced by the forces of commonality of implementation and support as expressed in the open source community. The proprietary Unix community was therefore unstable, due to the fragmentation force not being balance by the unifying force we have in open source, making us more stable, hopefully and so far, stable enough to avoid their fate. >> 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 Point taken. The (possibly wrong) assumption on my part being that as time moves forward and amd64 becomes the common platform that x86 is today, UPSTREAM (in the plural) will tend to converge on the LSB/FHS in reference to its spec for multilib on amd64. 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. >> 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? 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? Presumably, the situation will continue to be less stable for Gentoo-amd64 users than many of them would prefer, until Gentoo has finished switching, until portage has dual bitness tracking, and the lib/lib32/lib64 thing is all straightened out. >> 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. To answer your question, however, do you see the "I'm expecting" in what you quoted? What about the "it's possible that"? It should be fairly clear from those and the rest of the context that this part was simply my speculations, based both on what I know to have happened in the past, and on the various blogs, meeting logs, and dev and amd64 list comments by devs, then filling in the gaps and projecting the trend forward. The key is, it's my speculation, and the phrasing I chose /should/ have made that quite apparent. I'm resisting the urge to make stronger snide comments, returning yours in kind, because I don't see how doing so would be conducive to a more informed list. I'll accept your disagreement. That's fine. If there's a different plan and my incorrect post ends up bringing it out, GREAT! I and other list participants will be the better informed, and therefore, better prepared to do our jobs as system admins, aka Gentoo users, because we know better what to expect ahead. I don't believe it's necessary, however, to take things personally, or to make personally cutting comments like the above, and honestly try to refrain from doing so, myself, tho I certainly can't and don't claim perfection in that or any other area. Back to the question... Can we agree that it's a fact that we (meaning the devs moving it, and the rest of us continuing our life as Gentoo-amd64 users amidst the mess of "construction", as it were) are most of the way done with the task of ensuring that 64-bit libs go to lib64, not lib? I know the reasons given for going to all the trouble, based on previous dev comments. Are you saying that has changed? If so, than certainly, what I clearly marked as my expectations, are going to be incorrect, as they obviously are if I got something wrong along the way. 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! 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! 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 reasonable and useful, great, if not, they can take someone else's. My opinion was freely given, and I really couldn't force someone to respect it even if I /wanted/ to, which I don't. If they want to value it at what they paid for it, no skin off my nose! It's their life and their opinion, which they are certainly as free to have as I am to have mine! >> 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...) OTOH, "now" could mean "currently", in which case, I'd generally agree. Gentoo-amd64 is not in the position, currently, to do "real" multilib, even if portage supported multi-track dependency resolution. Then of course, there's the whole question of what defines "real" multilib... Or it could mean something else. In any case, I'd welcome any enlightenment you might be able to provide, on the subject, or for that matter, on anything else list related. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-amd64@gentoo.org mailing list