Comment 12 for bug 689615

On 14.12.2010 17:07, Martin Pitt wrote:
>> did I say that?
>
> You didn't; as you didn't explain what the solution _is_, I was trying
> to infer it from the diff.

citation out of context. there are three questions, not just the last one.

>> the changelog is quiet explicit about the changes.
>
> The changelog doesn't attribute any particular change entry with this
> bug, and most changes apply to the pycompile program, and the changelog
> doesn't specify which part of it (function name or so), it's also hard
> to say. It seems to me that the entire second block in the changelog are
> extra changes which are unrelated to this bug.

fine. I'll retitle the bug.

> This would go a lot faster if this update would actually follow the SRU
> procedure..

All changes are appropriate for a SRU, and were made in natty before filing this
issue. And I think it is not appropriate to insist on untested
dependency/breaks changes, which I did tell you were no solution, and delay the
fix for real issues, and which did cause new issues in natty.

 > The changes to public_modules.rtinstall and public_modules.rt remove
 > seem irrelevant for this SRU, as we don't support 2.4/2.5 in maverick,
 > right?

please re-read the patch and the changelog:

   * Don't touch the standard python library in rtupdate scripts.

even maverick has a site directory.

the change for the particular upgrade problem is

   * pycompile:
     - if installed Python is requested via -V option, use it even if
       it's not in a list of supported Python versions

Yes, having this fix in maverick doesn't solve the upgrade problem for
installations with disabled -updates, but it will avoid us tons of bug reports
for installations with enabled -updates.