On Mon, 2004-08-23 at 18:32, Jeff Pitman wrote:
> I've seen this floating around a few spec files:
> %ifarch ia64
> %define depsuffix ()(64bit)
> %else
> %define depsuffix %{nil}
> %endif
>
> Then, later:
> libwhatever.so%{depsuffix}
Oh.
> But, maybe this is a very old way to do it and they now pile it on
> inside of /usr/lib64/. I have no idea.
It probably has something to do with x86_64 which can use 32-bit and
64-bit apps/libs but I guess they cannot be mixed or something (eg. a
64-bit Mozilla probably cannot use 32-bit plugins).
(But this stuff deserves a new thread, I bet it's not getting the
attention of the people who know it here.)
> Someone needs to donate 64-bit systems to both of us!! ;)
Yeah, send 'em over!
> > AFAIK upstream Python distutils has differentiated between the two
> > already for a long time, and it certainly does so nowadays.
>
> I would actually presume that the differentiation is rooted in autoconf
> and just carried over into distutils as a matter of reference.
Or Perl.
> I have only been working the Unix scene for 7, 8 years and I've not seen
> much use of ./configure --exec-prefix.
Me neither but the support is there for those who want to use it, and I
guess there's a reason to use it in some situations. BTW --exec-prefix
seems to be fully supported also in rpm's default config, see %configure
and %{_*dir} in /usr/lib*/rpm/macros.
> Why? Is it because 64-bit can simultaneously run 32-bit libraries and
> 64-bit libraries at the same time and they're concerned over name
> clashes? Do they segregate 32-bit and 64-bit libs into different dirs?
> Maybe some programs can only have half their libs in 32-bit and the
> other half in 64-bit because of compilation issues.
Perhaps. AFAIK only x86_64 can use both 32- and 64-bit stuff though,
ia64 only the latter.
> *Sigh* I've still have not put a finger on this. It seems people like
> to throw Python "apps" in /usr/share/app_name and libraries
> into /usr/lib/python2.3/site-packages. I'm not
> sure /usr/share/app_name really makes any sense all the time.
Certainly not all the time, but if that stuff is intended to be used
only within a certain executable and is not generally useful,
site-packages would not sound good to me.
> Trick question: is epydoc an app or is it a library?
I don't know epydoc, but based on the description on the homepage, I
could imagine both (eg. basic command line executables in /usr/bin, some
Python modules in site-packages that could be used by imaginary
additional frontends).
