Some Python Packaging Questions

Ville Skyttä ville.skytta at iki.fi
Tue Aug 24 22:48:26 UTC 2004


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





More information about the fedora-devel-list mailing list