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

[Duncan <1i5t5.duncan@cox.net>]

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 <g>). 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! <g>

>> 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