On Tue, Oct 23, 2001 at 02:42:42PM +0200, Gregor Hoffleit wrote:
> Just to make the discussion a little bit more focussed: I think several
> issues were mixed up in my original mail:
Sounds like a plan.
> (1) For once, #!/usr/bin/env has it's problems. Scripts that use
> "#!/usr/bin/env python" are more fragile than scripts without.
>
> (2) Another issue is "python" vs. "python1.5". It's a separate question
> whether scripts need to be strictly coupled to a specific Python
> version.
>
> Regarding (1): If you ask me how common the situation is that people
> install local Python versions in /usr/local, then I will ask you how
> common it is that it's reasonable that a script provided by a Debian
> package will benefit from using #!/usr/bin/env ?
Well, how about you answer the question instead?
It's reasonable for Debian scripts to use #!/usr/bin/env because any
harm that could be caused is both rare and easily avoidable, and because
that's what many upstream scripts use. AFAICS.
(I don't really care if you want to encourage people to not use
/usr/bin/env, though)
> Regarding (2): Making the dependency explicit (by using
> /usr/bin/python1.5) is just playing safe.
It's not merely playing safe though. It's also creating a strict
dependency that will bite you later (by making transitions to python X.Y++
require significantly more changes, by having packages break needlessly
when those changes aren't made).
> As far as I can see, if we hadn't the legacy of the existing packages
> and installations, and if versioned dependencies would work on all
> systems in all situations, we could come up with a quite clean setup:
> python-base et al. could be empty packages (virtual packages wouldn't
> work!), and other packages could depend on them (e.g. "Depends:
> "python-base (>= 2.0), python-gtk" for a package that need at least
> Python 2.0 or better. Still in this case, what could you do if Python
> 2.3 broke that script ?)
There're two possible solutions, obviously: either you assume in advance
that scripts will work with new versions of python and allow them to be
installed together, or you assume they don't and forbid them from being
installed together.
I think that's a correct statement: I can't see any other possibilities
being even logically consistent.
If you assume that scripts will work with new versions of python,
you end up with the result that occassionally your assumption will be
wrong for some scripts, and you'll have some possible partial upgrades
that'll break. This isn't a cardinal sin.
OTOH, if you assume that scripts *won't* work, you're committing
yourselves and a bunch of other people to going through whole bunches of
Python code checking that it works, and twiddling bits to note that fact.
The only question is whether the (presumable) handful of bugs every year or
two due to the former is worth the (presumable) whole lot of effort involved
in the latter.
The easiest way to handle the latter, IMO, is to add a:
Depends: python-base (<< <X>.<Y+1>)
to the package, where <X>.<Y> is the most recent version of python that
it works with.
Note that this allows you to use a package on multiple versions of python
(so if woody were to release with python 1.5 and 2.0, your package could
conceivably Depend: python-base (>= 2.0), python-base (<< 2.3), and you
won't have to make further changes when Debian packages for 2.1 or 2.2 come
out), unlike #!pythonX.Y, which is much more restrictive.
> As far as I can tell our principal problem is that there's a large set
> of existing packages (from slink, potato) that have wrong dependencies
> (like unversioned "Depends: python-base" for packages that depend on
> Python 1.5.2) that would be (erronously) satisfied if we just continued
> to use python-base and so on.
Well there's two questions; one is working out what we want, and the other
is working out how to get there.
> One way to resolve this is to include a huge list of conflicts in
> python-base et al.
> Another way to resolve this is to drop these package names, perhaps in
> favour of some other package names.
The easiest would be to say "Packages that have an unversioned dependency,
or just a >> dependency and expect version 1.5 (but not 1.6 or 2.0 or
so on) are broken", and not care.
Depending on how many packages actually expect python 1.5, this might
even be a reasonable thing to do (if you go the route of buring the future
backwards incompatabilities bridge when you come to it, this only matters
for modules, which can probably be pretty easily replaced in one shot).
Switching the package name from "python-base" to "python" would be relatively
easy too, if the dependencies aren't maintainable.
> It's much the same reasoning why libraries have a number in them that
> will be increased for incompatible API changes. AFAICS, with the setup
> you are suggesting you can never warranty that kind of robustness.
Bumping library revisions usually just requires a recompile though,
with absolutely no source changes at all. Changing #!/usr/bin/python1.5
to #!/usr/bin/python2.0, OTOH, doesn't. One can be done trivially by an
autobuilder, the other can't.
And again: the focus here (IMAO) should be on maintaining a single,
canonical version of Python in the distribution. Having older versions
and brand new beta releases around is nice, but having the main version
be simple to handle and robust seems a lot more important. (Saying "Hey,
Debian's Python is 2.1.1! But you can't install 1.5 in /usr/local without
taking some care" is way better than saying "Debian's Python is 1.5! Yeah,
we know that sucks, but hey, you can install 2.2 and 1.6 and 2.0 all at
once into /usr/local and nothing will ever break no matter how screwed
up it is!", eg)
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt
Attachment:
pgpkHDcJkKEvV.pgp
Description: PGP signature