--=-=-=
Content-Transfer-Encoding: quoted-printable


  What is a typical python infrastructure if there such a thing? GNU Radio=
=20
  installs into <PREFIX><PYSITELIB>/gnuradio. Can you tell me how it differ=
s=20
  from py-distutils?

Other than failing to set the interpreter to the chosen version, I
think GNU Radio's build system is fine.  Yes, it doesn't use
py-distutils.  If py-distutils replaces the interpreter, then yes, it
would be an improvement.   But Linux and therefore python culture is
to put everything in /usr/bin - just like the '#!/usr/bin/perl' we
see so often.

  I'm almost at the point to give up on pkgsrc. In many cases I find it muc=
h=20
  easier to take a third party package and install it into /usr/local=20
  filesystem as its done by most distros.

I don't get this.  pkgsrc has some difficulties, but on balance it
saves vast vast amounts of time.  I have (shudder) 443 packages
installed on one system right now - and as of yesterday only 2 were
out of date.


I've talked to Eric and discuss-gnuradio about this.  I think what
pkgsrc is doing is right, and that scripts with "#!/usr/bin/env
python" (that do anything other than builtin python stuff) are simply
broken.  This view is not shared by everyone.

The point that I think Joerg was making is that at configure time some
program looks for extension modules, and if python has some features,
etc.  Then it's built against that version of python, and this is
accentuated by where it puts the compiled modules.

If the 'python' version were to change from 24 to 25, and the
extension modules not rebuilt for 25, the program under discussion
would simply fail.

So, the only sane things to do are

1) only allow one python version to be installed, so that everything
   has to be rebuilt by pkgsrc if the version is changed

2) make everything bind at build time to a specific version, so that
   changing alternatives or installing other versions doesn't lead to
   broken programs


Option 1 is not good, because many programs seem to need particular
python versions; upgrading is not always ok.  If this is really true,
it speaks poorly of python's rate of dropping backwards compatibility.
Note that we're doing this with perl, but it seems ok with perl.

Option 2 requires PYTHON_PATCH_SCRIPTS for packages that are broken
upstream from the 'strict binding' viewpoint, which GNU Radio is.
While annoying, this doesn't seem that hard.

I have applied fixes to GNU Radio to use the found python binary
explicitly when invoking python to check for wxwidgets, and that now
works fine.

All that said, I have a symlink in /usr/pkg/bin/python because mucking
with GNU Radio is otherwise too annoying.

Could someone who uses Linux explain

  how most GNU/Linux distributions handle multiple versions of python
  (different names like we do, not allowed, etc.)

  how GNU/Linux distributions deal with /usr/bin/python: present, and
  if so refers to what?  controlled how?

  how GNU/Linux distributions behave if one installs e.g. a GNU Radio
  package built against python24, and then installs python25, and then
  sets python25 to be the default so that /usr/bin/python refers to
  2.5?

It may be that there's a way out that we are missing.  But so far no
one has explained how this can work without binding to the specific
version at build time, where "work" implies one can switch default
versions without breaking existing installed packages.  I am under the
impression that the standard approach on GNU/Linux is to trade
reliability for ease of use.  It's hard to say that this is an
unreasonable decision, even though my preference is for reliability.

=2D-=20
    Greg Troxel <gdt@ir.bbn.com>

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iD8DBQFFfdRR+vesoDJhHiURAuvXAJ9g+y2RoojHnvfpdjxs1MhjrB9CCACdFIqi
z0ui2NyKaQKmC93WUNmGIfI=
=nNQc
-----END PGP SIGNATURE-----
--=-=-=--