Comment 4 for bug 237654

> 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.