[... just recovering from LT2k++ and other recreational things ;-)]
Thanks, Chris for your suggestions:
On Wed, Jul 04, 2001 at 09:00:06PM -0500, Chris Lawrence wrote:
> My semi-well-thought-out solution:
>
> - python-* should provide a "Standard" Python for each Debian
> release. 2.1.1 seems a sensible target for woody. These packages
> should be invoked by /usr/bin/python and /usr/bin/pythonx.y
>
> - python-* should (virtual) provide python-x.y-*.
>
> - python-v.w-* (where v.w != x.y) can exist at the discretion of the
> Python maintainer. Provides /usr/bin/pythonv.w
> I recommend at least having 1.5.2 in woody. 2.0.1 may also be
> useful. I don't see any good reason for us to ship 1.6.1.
After banging my head a few times, and realizing time constraints, this
currently looks to me like the most practical solution for woody:
Simple rule of thumb: Each package that installs stuff in
/usr/lib/pythonX.Y/site-packages has to depend on python-X.Y-base.
Then, if we had a package python-base (1.5.2-x), it would "Provide:
python-1.5-base". Later on, a package python-1.5.2-base might
automatically fulfill this dependency, when python-base is at version
2.1.1-z (which would provide, in turn, python-2.1-base).
> - The complete version number of Python should appear in the version
> field. I recommend using X.Y(.Z)?[abcfp](N?)-rev; this also complies with
> Debian's sort order. .Z and N can be omitted if 0. However, f is
> mandatory for a final release, to maintain sort order.
> (Packages built from CVS could be 2.2a-2001xxxx.)
Hmm, I don't like that "f". IMHO CVS versions should be invisible for
the normal user; it's the definite goal (where possible) to have only
released upstream versions in our Debian releases.
Even if it looks more ugly, I'd prefer either 2.1.999-2001xxxx or
2.2-0.2001xxxx.
> - Packages that don't care what Python is installed can depend on
> python-*. Most simple Python packages fit here. If any features
> used are deprecated in the most recent X.Y release, they can depend
> on python-* (<< X.Y+1). They can use #!/usr/bin/python.
That is packages *using* Python (contrary to packages extending the
Python library), you mean.
> - Packages that provide Python-language library modules:
> - Depend on python-v.w-* | python-y.z-* | ... for all versions they
> can run on.
> - Provide /usr/lib/pythonX.Y/site-packages/... for all versions they
> can run on; I'd use symlinks if the code needn't change.
> - Invoke compileall.py for each version available.
> - Run python-wrapper-config * in postinst and postrm.
>
> - Packages that provide binary-linked library modules:
> - Depend on python-v.w-* | python-y.z-* | ... for all versions they
> can run on.
> - Build-depend on python-v.w-*, python-y.z-*, ... for all versions
> they can run on.
> - Provide /usr/lib/pythonX.Y/site-packages/... for all versions they
> can run on.
> - If two releases share the same API version, the same binaries may be
> shared in site-packages. (Not sure if this happens in practice.)
> - Follow the above policy with regards to any Python-language
> modules.
> - Run python-wrapper-config * in postinst and postrm.
>
> - Python packages that need particular modules: This is sticky.
> - Depend on the needed packages to provide the modules.
> - Depend on python-* (>= X.Y) if it uses features unique to X.Y+
> - In postinst, figure out the python-x.y packages that are
> installed and provide all necessary modules and fulfill the
> dependencies for this package. Write this to a file.
> (This is handled by "python-wrapper-config" *)
> We need to register each package that cares about this in
> a file (/var/lib/python/needs-wrapper *) for module postinst/rm.
Sounds quite fine to me. This could even serve as a beginning of a
Python policy.
It certainly sounds arrogant if I say that this sounds quite similar to
what I envisioned in the last days ;-)
> We are guaranteed to have at least one Python version that works
> if one module is involved by dependencies. If multiple modules
> are involved, we may have zero working versions (which is a bug)
> and will be detected by this step, causing package install to fail.
>
> How to do this:
> - Executables use #!/usr/bin/python-wrapper (*)
> - Have a file /var/lib/python/wrapper-config (*) with
> executable: version1, version2, ...
> This is written by the postinst.
> - Have a python-wrapper that reads $1, figures out which executable is
> involved, and invokes the appropriate python. (It can probably
> be in Python itself... perhaps provided by python-x.y-base and
> managed by alternatives.)
> - This "figuring out" will have to be done by each python-x.y-*
> and each modules package on install and remove too.
> - Remove this cruft in the postrm.
>
> (*) Rename this to something better if you like.
>
> The main disadvantage is that people compiling binary-linked library
> modules will need multiple Pythons installed; of course, unless some
> magic API fix comes along, they would anyway.
>
> It also doesn't include any way to accomodate locally-built Pythons,
> unless they are built and installed as debs. This may or may not be a
> problem (some people may want to track CVS).
>
> I think this covers all of the important issues though. It may be
> needlessly complex, but it does support users having whatever Pythons
> they want installed and should allow most things to work.
I have a pretty good feeling with this solution.
Sounds pretty dumb, but the missing key point in my thoughts was the
virtual package "python-X.Y-base" (perhaps python-X.Y is better ?). I
just didn't get it, and always thought about ugly solutions involving
multiple versioned dependencies.
But, as Carey Evans already mentioned, we have to make up a solution for
the existing potato packages that have incomplete dependencies (like
"python-base (>= 1.5.2-1)") for the case where a user just tries
"apt-get install python-base" with woody. If Python 2.1.1 would include
a python-base package, these (buggy) potato packages wouldn't get
upgraded. OTOH, I don't want to include a long list of conflicts with
a python-base 2.1.1 package.
Gregor
