[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Migrating a package from from python-central: cleaning up (was: Piotrek's new preferred helper tool - (unfair) decision)



Piotr Ożarowski <piotr@debian.org> writes:

> PS while converting [from use of ‘python-central’ to use of
> ‘python-support’], remember to add to preinst something like these 3
> lines:
> 
> | if [ "$1" = upgrade ] && dpkg --compare-versions "$2" lt 1.2.3-4; then
> | 	pycentral pkgremove python-foo
> | fi

As noted elsewhere, this is to overcome behaviour (discussed in
<URL:http://bugs.debian.org/479852>) that is the default for
‘dh_pycentral’: “create symlinks on postinst, don't clean up on
prerm”. Because it is the default, this likely plagues a significant
portion of ‘python-central’-based packages already installed out
there.

The approaches suggested in the ‘dh_pycentral(1)’ manpage are:

    This can be disabled by setting the environment varibale
    DH_PYCENTRAL to a string containing the string noprepare. If the
    newer version of a package needs to remove the symlinked files on
    upgrade, either the package needs to take care of the removal by
    calling pycentrel pkgremove in the new preinst, or leaving a file
    /var/lib/pycentral/<package>.pkgremove and using pycentral 0.6.7
    or later for the old package version.

I, like Piotr, am now preparing to migrate my Python packages to use
‘python-support’ (once the new version that stops using ‘/var/lib/’
hits ‘testing’). What is my best approach for preparing to do this? As
I see it, the existing documentation suggests one of:

  * Leave the package for now depending on ‘python-central’, set
    ‘DH_PYCENTRAL = noprepare’ in my existing packages's
    ‘debian/rules’, then build and upload a new release; or

  * Migrate the package immediately to use ‘python-support’, put the
    call to ‘pycentral pkgremove foopackage’ in ‘preinst’ as shown
    above by Piotr, then build and upload a new release; or

  * Migrate the package immediately to use ‘python-support’, create an
    empty ‘${DESTDIR}/var/lib/pycentral/foopackage.pkgremove’, then
    build and upload a new release; or

  * Something else (please specify).

Which of the above is best in general? What reasons would I have for
not doing the same thing to every affected package? How long should I
leave these measures in place before removing all mention of
‘python-central’ from a new release?

-- 
 \       “When I get new information, I change my position. What, sir, |
  `\             do you do with new information?” —John Maynard Keynes |
_o__)                                                                  |
Ben Finney


Reply to: