SRU for hardy

Matthias,

What is the SRU justification here, please? The only LP bug number referenced in the changelog other than this one is bug #225927, whereas there are a significant number of other changes mentioned in the changelog; and per my comments at the bottom of bug #225927, I don't think that bug itself warrants an SRU.

updated comment in 225927. sounds like pain if we can't fix an upgrade error.

please see the "->" comments in the changelog. these are not reviewed.

> Normally the symlinks are not removed on upgrades, to keep files
> available during upgrades. We need a way to remove these on upgrade
> to package not using pycentral in the future. This lets the preinst of a new version
> of a package drop a file, so that the symlinks are removed on upgrade in any
> case.

Do I understand correctly that no packages will be uploaded to hardy that make use of this new functionality - it's only being added to ensure that packages in intrepid or later, which previously used python-central but no longer do, can rely on this functionality being present without having to have a versioned dependency on python-central? I'm ok with such an infrastructure change in SRU, as long as it's /only/ an infrastructure change and doesn't change any existing behavior.

Fix for Debian bug #409390 - self-explanatory, no objections to including a fix in SRU. (Wasn't there also a bug in LP about this same issue?)

Bug #225927 - ok, I wondered if this were a dpkg consistency question, but didn't realize this had been confirmed. Your proposed fix is definitely reasonable there.

> * pycentral updatedefault: Call py_compilefiles with `-f' for private
> modules.
> -> we can't rely on the timestamp, if we change the default python version

Is there a bug reference for this? I don't have enough context here to understand what this is about. What timestamp was being relied on?

> * dh_pycentral: Install the preinst script for packages having
> private modules; really closes: #477180.
> -> needed for updates with new or non-existing files in the new version.

Which change in the source does this correspond to? I don't see any changes in the diff that look like they fit this description.

The other changes don't look to me like they warrant inclusion in an SRU (one is a change to a build-time tool, and there's no mention here of packages that need to be rebuilt once these fixes are available; the other is a fix for /usr/bin/python not being a symlink, which it always is when using distribution packages), but I won't reject the SRU on those grounds either. But please answer the question in the preceding paragraph.

we can do the patches dealing with the upgrade scripts later; here is a reduced version of the update only addressing the runtime behaviour of pycentral.

> Is there a bug reference for this? I don't have enough context here to understand what this is about. What timestamp was being relied on?
no, when byte-compiling pycompilefile only builds the byte-code file, if the .pyc file is older than the .py file without looking at the version of the byte-code file.

> Which change in the source does this correspond to? I don't see any changes in the diff that look like they fit this description.

this is the last chunk of the patch to dh_pycentral.

Looks generally sane to me now,I accepted the original upload. Matthias, can you please add some TEST CASE:s for verifying?

I've added two test cases for two of the changes included in this SRU. Most of the other changes are not readily testable because they are changes to python-central's functionality as a build-dependency, so they can only be tested by building packages against python-central that include specific features.

I'm going ahead with copying this to hardy-proposed on the basis that these test cases have passed for me, that no other regressions have been reported against python-central in this time, and that we have a regression in hardy-updates, filed as bug #242554, which has resulted from aptoncd being copied to hardy-updates in advance of python-central.