Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> Stephen Leake wrote:
>> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>>> The reason for all this is that when a package libX2-dev Conflicts:
> with
>>> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
>>> and install libX2-dev; instead, it marks libX1-dev as broken and leaves
>>> libX2-dev uninstalled.
>>
>> This seems like a clear bug in aptitude.
>>
>> Debian policy 7.6.2 says that Replaces: with Conflicts: should cause the
>> old package to be removed, and the new package to be installed, so why
>> doesn't this work?
>
> That's because there is no conflict until the user asks for installation
> of the new package; 7.6.2 says the old package must go only in case of a
> conflict. So, I would not characterize the behavior of aptitude as a
> bug, merely an annoyance.
Ok.
But it seems the best way to reduce the annoyance is to improve aptitude
(or dpkg). Add an option that says "treat Replaces as the correct
upgrade path". Or add a new control field Upgrades for that purpose.
Currently, a package is upgraded only if its name does not change.
Package names can change, either because of aliversions, or for other
reasons. So an Upgrades control field to identify package name changes
would be appropriate. Or maybe it should be a Renames control field.
That could also allow uploading without going thru the new packages
process.
However, my reading of Debian policy gave me the impression that
Replaces was supposed to be used for that purpose. Since the tools
currently do not fully support that use, I think they are broken.
Another option would be to teach dpkg to treat the aliversion in the
same way it currently treats other version numbers; that is, not as part
of the name, so it would know that libopentoken2-dev is the proper
upgrade from libopentoken1-dev. We might have to add some separator
syntax for the aliversion for that to work.
--
-- Stephe
Reply to: