On Thu, Dec 22, 2005 at 06:44:19PM -0500, Jack Howarth wrote:
>      While testing the apbs and pdb2pqr packages (which run their python
> scripts using /usr/bin/python), I discovered some potential breakage. The
> current info scripts for these packages have a Depends on python. However
> since these packages (at least pdb2pqr for sure) build extensions against
> the python headers this seems very bad. The configure script in pdb2pqr
> identifies the python version by looking for the binary. If the python 
> package from python2.4 is installed and pdb2pqr is built, it will be
> built against the headers from /sw/include/python2.4, whereas the pdb2pqr.py
> script will run against python2.3 using /usr/bin/python.
>
>       I considered making a python variant of apbs and pdb2pqr but that is
> far too complex since apbs depends on pdb2pqr. It would be pointless to
> try to juggle all those python versions.

It only really makes sense to do python-versioned variants when there
are public libraries that other packages may want. If all you have is
a script and private support libs, no reason to do -pyXX games.

> Since apbs and pdb2pqr don't make graphical calls (hence no X11), it
> seems rational to stick with the system python. However I don't see
> a system python virtual package in fink.

In general, there are only system virtuals for things that are
optional or may exist in different versions. All 10.3 and 10.4
machines have python2.3 (part of the BSD package I think).

> My proposed change is...
> 
>  Package: apbs
>  Version: 0.4.0
> -Revision: 1
> +Revision: 2
> -Depends: maloc, readline-shlibs, gnuplot, python, pdb2pqr 
> -BuildDepends: g77, maloc, python 
> +Depends: maloc, readline-shlibs, gnuplot, pdb2pqr 
> +BuildDepends: g77, maloc
> +BuildConflicts: python
> 
> which insures that the python extensions are built against the system python 
> headers. However, we have a number of packages like eden, pydns, reportlab,
> pmw, etc that Depend on python such that they must be deinstalled for the
> build. I suspect those packages are broken since I don't see how a simple 
> Depends on python can keep the version straight. For example, if any
> package that depends on python is built against python headers, there
> will be the possiblity of mismatch if the user ever swapped the python
> package from one version for another of python. Then the program would
> execute against the wrong python if it expected /sw/bin/python to be
> the same version as when it was built.
>     Is this a correct analysis? I assume fink packages should be allowed
> to build against the system python without forcing other fink packages
> besides python to deinstall. Also it seems that depending on python itself
> is a very risky approach to packaging, no?

As you note, the "python" package is usually not a good choice for a
dependency. It's mostly for user convenience (being able to get fink's
python as the first "python" in PATH). Nothing that compiles (even
.pyc, but *especially* not compiled C or other things that interact at
a binary level with python itself) should use it.

OTOH, packages do use it (sometimes even correctly:) and users like
having it. BuildConflicts:python is usually a last-resort solution.
It's not user-friendly, and it's even not completely functional in
some fink versions.

Can you adjust the package build process and/or its resulting scripts
to use a specific path to python (/usr/bin/python for example) instead
of just using "python" and relying on finding it in PATH? That means
the presence of the fink python package is irrelevant.

Alternately, many maintainers of packages that need "any version of
python" but not a non-deterministic one just pick a flavor they like,
add Depends on it by version ("python24") and patch the package to use
that executable's name ("python2.4" for a PATH-based search or
"%p/bin/python2.4" to be certain).

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Fink-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to