Re: dependencies of non-module packages
On Mon, Aug 26, 2002 at 09:11:38PM +0200, Federico Di Gregorio wrote:
> hi,
>
> i just had a little email exchange with Christian Kurz about dput and i
> think the python policy need to be clarified. some background...
>
> last upload of python broke dput dependencies: they were
>
> python (>= 2.1), python (<<2.2)
>
> because even if dput is supposed to work on 2.2 it was never tested.
> now, because dput is _supposed_ to work on multiple python versions
> (even if now n = 1) the packager did not make it depend on a versioned
> version (no pun intended) of the package.
>
> the policy seems clear enough to me but maybe i am wrong or the policy
> is not completely clear. my interpretation is that a non-module package
The policy focuses on modules, because they are the most complicated.
> (i.e, containing only end-user scripts) that depends on _some_ versions
> of python should depends on any of the valid versioned packages. example
> for dput (when tested on 2.2):
>
> python2.1 | python 2.2
>
> mm.. but that does not pull the right *default* python if not yet
> installed. so what about the versioned main package and then the valid
> alternatives? mm..
If dput is purely a script with no modules, you life is easy. Assuming it
works with python versions 2.1 thorough 2.2 inclusive, and you want it to be
used with the default version of python, whatever that is, you should do the
following; Use "#!/usr/bin/python" and "Depends: python (>=2.1), python
(<<2.3)".
This means the script will run using the default python, and the package
will install with python (2.1) or python (2.2).
If dput has some modules with it that must be compiled, your life gets much
harder. The first complication to consider is where to put the modules and
their compiled *.py files. You can put them in their own "/usr/lib/dput/",
the standard "/usr/lib/python2.1/site-packages/", or the python-central
supported "/usr/lib/python/site-packages/".
If you put them in their own "/usr/lib/dput", your postinst scripts will
have to compile them using the default python. Your scripts should use
"#!/usr/bin/python" and your package should have "Depends: python (<=2.1),
python (<=2.2)". You _could_ use "Depends: python (>=2.1), python (<<2.3) to
support python versions 2.1 through 2.2, but the problem is when the default
python upgrades from 2.1 to 2.2, your modules will need to be recompiled but
nothing currently will do this for you. End users will need to run
"dpkg-reconfigure dput" manually to ensure the modules are recompiled after
installing the upgraded python.
If you put them in "/usr/lib/python2.1/site-packages", then use
"#!/usr/bin/python" and "Depends: python (<=2.1), python (<=2.2)". You
cannot support multiple versions of python because the modules need to be
located in different "/usr/lib/pythonX.Y/site-packages" directorys. When the
default python upgrades you will need to update the package, moving the
modules into the new versions site-packages directory.
If your use python-central, you can support multiple versions of python
simultaneously. This is probably not that useful for scripts as oposed to
modules, but here is how you could do it; use "#!/usr/bin/python" and
"Depends: python2.1 | python2.2, python-central". Install your modules in
/usr/lib/python/site-packages and have your postinst scripts call the python
central supplied "register-python-package" to link and compile them for all
the supported and installed versions of python. Optionaly include simple
scripts "dput-python2.1" and "dput-python2.2" that execute the dput script
using the specified version of python. Note that python-central is not yet
officialy supported.
After going through your options I can see why the Mailman mantainer was
complaining in more detail. The first option is the most attractive for a
script-with-modules package. However to make this really attractive the
default python package should run "dpkg-reconfigure" for all installed
packages depending on "python" in it's postinst script when the default
version of python is upgraded.
I'd like to recommend this behaviour, in conjunction with python-central
support, to become standard.
Note that rpm packages support the concept of "trigger scripts", that
presumably would allow you to do things like have dput recompile its
own modules when python is upgraded. dpkg doesn't support this, and until
now I could not see how it would be useful.
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: