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

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

Simon Stelling posted <42F7B071.7060603@gentoo.org>, excerpted below,  on
Mon, 08 Aug 2005 21:20:17 +0200:

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

Hmm...  Maybe it's because I've been quite active on USENET (and public
mailing lists like this one, now) for some time, but to me, that's just
the nature of the medium.  Two or sometimes five or ten replies all
stating the same thing or sometimes wildly different things <g>, just
comes with the territory.  Sometimes folks build on what others have said,
sometimes they disagree and say why, sometimes the posts don't have any
relation but say essentially the same thing, because neither poster saw
the other's post before they posted.

IMO, it's one of the strengths of the medium that each poster says it his
own way, most rather briefly, some (like myself) taking hundreds of lines
to explain (their view of) why things work as they do, the implications,
and some of the exceptions to watch out for and what to do to avoid or
work around them, all to the Nth degree! <g>  Basically, it allows the
original poster (aka OP) to pick and choose the replies that meet their
needs.  If they want a quick solution, the five line "do this" is perfect!
If they want to know the background and what to do to prevent the issue
again, and/or how to fix similar but not identical issues, without having
to post another query, the next time, then the 200-liners <g> come in
handy.

So... yes, occasionally someone gets offended.  However, once they
understand the medium, they generally don't any more, and, as always with
the medium, for those seriously offended, there's always the kill
file/filter option, the exercise of which does not require notice or
reason be given.

>> [W]hat about binary only installers?
>
> 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.

Hmm.. surprised me on the hardcoding being mostly open source...  I guess
it makes sense, tho, as the OS folks figure it's open, so folks can change
it if need be, while the closed source folks don't /want/ folks examining
their stuff, so have reason to make it configurable.

However, the real point is dealt with below...

>>>>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
> 
> '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.)

Ah...  I see your viewpoint, now!  It never occurred to me...

I was using "efficient" as in "getting as far as possible using the least
amount of work and resources possible".  Thus, "efficiency" is usually
thought of as having a good effect, but is actually neutral, in that
something can be "ruthlessly efficient", or "an efficient killing
machine", or the like, in which case the effect can be bad, depending of
course on one's viewpoint, whether one is doing the killing or being
killed (or watching it occur, with approval or disapproval), in the case
of the "efficient killing machine", for instance.

Thus, here, I was saying it's "less work and requires less resources" to
go with the community common standard.  That's ALWAYS the case.  Whether
it's actually worth spending the extra work and resources, therefore,
depends on just what value is assigned to the proposed difference from
standard, in question.

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

The trouble is... what's self-evident to one person, isn't always so
evident to another!  I've unfortunately had to find this out the hard way
on more than /one/ occasion!  <g>

Anyway, here, the context was in how that forms the unifying force that
keeps (GNU/)Linux from fragmenting into incompatibility, as proprietary
Unix did, and how that forms a counter-balance to the forces of
fragmentation.  The argument is quite familiar to those who've been around
open source for some time, certainly, but evidently, it isn't quite
self-evident to everyone, as the question of fragmentation does continue
to come up.

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

It /would/ be nice...

[snipping a section I entirely agree with, post was getting too long...]

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

OK, got it!  The case of the missing smiley chalked up another victim,
here, I must admit!  (See next for content comment.)

>> The key is, it's my speculation, and the phrasing I chose /should/ have
>> made that quite apparent. [snip]
> 
> 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? [snip]
> 
> 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.

OK, it's clearer now what you were referring to, and indeed, I agree,
I could have been clearer in specifically stating it was NOT a devs
roadmap.

I'll plead the "I'm still learning" excuse, here. You make a
decent point. I've been personally in the process of coming to terms with
what it might mean for me to be a Gentoo AT, and the implications that
should/will have for my posting. I've been a user, only a user, if perhaps
a somewhat influential one, in 100% of my USENET and mailing list rolls,
for as long as I've had such rolls. As such, I've not had the
responsibility of representing someone else, and could speak my mind,
because it was /only/ me I was representing.  I take seriously the advice
in the AT guide, and have been considering the implications that will have
on my posting style, as well as whether I'll choose to post with my Gentoo
identity (once I get it, let me be absolutely clear lest anyone be in any
way confused, I don't have it nor do I claim to have it yet) as part of my
regular sig, only some of the time, or if I'll only use it with the devs
and on bugzilla.

Quite apart from AT, however, it just happens to fit in there too, you are
correct in that it would have been possible, indeed, preferable, that I
made it a bit more clear that the "we" I mentioned several times was NOT
"we" as in Gentoo-amd64 devs, but "we" as in the commonality of
Gentoo-amd64 users AND devs -- and that I was speaking as the "user" side
of that "we".  Specifically in this "roadmap", while I DID mention "I
expect", and "possible" and other such qualifiers, I COULD and SHOULD have
also specifically stated this was NOT a devs provided roadmap.  Again, I'm
still learning, but you've persuaded me.  =8^)

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

Aye.  Sometimes I'd rather be just a Joe Blow!  <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.
>> 
[snip speculation that proved /not/ to be the case, thankfully! <g>]
> 
> 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.

Very, /very/ good point.  It's one I'd thought of, but not really in this
context, and certainly not with all the implications, so there's some
rather new info for me here.  That's what I was hoping for!  =8^)

So, rather than the two aspects I had outlined, there are /three/, and
when I said that was only half, it was only a third.  MORE challenges to
work thru!

As an aside, I'd often wondered at the implications of having a
"multibin", similar to "multilib", and why, with all the work going into
multilib, nobody seemed to be doing anything with multibin.  I had
wondered why having a 64-bit mplayer for most stuff, and a 32-bit mplayer,
for 32-bit-only binary-only codecs, wasn't as reasonable a solution as
it seemed to be for libraries.  Your comments just touch on that, but
it's the first time I've seen /any/ sort of comments on the subject, from
anyone who'd be in a position to know the issues involved, from any of the
distributions.


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

I'll probably go over these tonight, after work.  (I /did/ see and
read with interest the thread on dev about modular xorg, tho I
haven't gotten to the that link either, to see how it's comming
along.)  Thanks for the additional links to read thru!

...  Anyway, /very/ glad to get this whole thing straightened out, again. 
I must admit, I refreshed the group this morning with a bit of
trepidation.  Feels good to be at peace with my world, once again! =8^)

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