Re: Ruby changes for Wheezy
[Adrian von Bidder, 2011-03-04]
> The way it's done is that the packages declare what versions of python they
> support:
>
> python-pygments, for example:
python-pygments uses dh_python2 which takes a little bit different
approach than dh_pycentral or dh_pysupport.
dh_python2 ships all symlinks in the .deb package, in contrast to other
two tools which create them at install time (package's or interpreter's
install time). That means if package doesn't provide extensions,
dh_pysupport and dh_pycentral packages do not need another upload if new
Python version is added to the list of supported Python versions.
All tools byte-compile these files at install time (.pyc or .pyo files
are not shipped in .debs) for all installed Python versions that are
supported by the package.
> Depends: python2.6 | python2.7 | python2.5, python (>= 2.6.6-7~)
python2.6 is first because it's the default Python version, after the
default Python version (if package supports it) all other supported
(by the .deb) Python versions are listed (from newest to oldest)
python (>= 2.6.6-7~) is here due to pycompile/pyclean scripts used in
maintainer scripts
> Breaks: python (>= 2.8), python (<< 2.5)
yeah, that's to avoid bug reports when someone will try to use this
package with (default) python 2.4 or python 2.8 (which will NEVER be
released, BTW). dh_python2 will create similar dependencies to those
generated by dh_py{central,support} if Breaks: ${python:Breaks} is
missing in debian/control (I like Breaks because... that's what
Breaks is for)
> Then, via triggers, the module is compiled to bytecode for all supported
dh_pysupport byte-compiles them via triggers, dh_pycentral and
dh_python2 byte-compile them in postinst (and remove .pyc files in
prerm)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Reply to: