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

Re: RFC: Proposal to combine diversions and Replaces into DEBIAN/replaces



Jonathan Nieder <jrnieder@gmail.com> writes:

> Goswin von Brederlow wrote:
>
>> Also converting from old style dpkg-divert to
>> the "replaces" file is simply done by removing all dpkg-divert calls and
>> listing the respective files in "replaces".
>
> This part is hazy to me, but Iâ??m willing to give it the benefit of the
> doubt.

Say you have a package that has diverted /usr/bin/tool and now you want
to change the package to use the "replaces" file instead. How would you
manage the transition?

Assuming dpkg wouldn't take care of this automatically you would have to
first remove the old style diversion in preinst before dpkg adds the new
style transition, which you can't because the diverted file conflicts
with the one you shipped in the old version. Or dpkg would create the
new style transition by probably renaming the wrong file and you would
have to shuffel files around and remove the old style conversion in
postinst in some hackish way to repair things again.

Overall that would create a huge mess risking the maintainers screwing
it up in every diversion using package. So I think it is essential that
dpkg automatically handles transitioning the diversions already in its
DB to the new "replaces" file syntax cleanly so that individual packages
can't screw it up. The information in the diversions DB of dpkg is
basically the same as packages will have in their "replaces" file so
that should not be a big deal to implement. It just moves the entries
from /var/lib/dpkg/diversions to /var/lib/dpkg/info/<pkg>.replaces.

>> The idea is that no effort has to be taken in the maintainer script to
>> keep the diversions in line. Simply listing them in the "replaces" file
>> is all that is needed.
> [...]
>> All the dangers and
>> dificulties of using diversions right is eliminated.
>>
>> Further replacing files becomes more specific preventing accidentally
>> replacing the wrong files and reversible. This would make the use of
>> Breaks + "replaces" file a safe operation unlike Breaks + Replaces is
>> now, not just when aborting an upgrade but even when downgrading.
>>
>> Comments?
>
> So whereâ??s the patch? :)
>
> Seriously, this sounds like an excellent thing to do, and best of all,
> it would be perfectly safe to include something like this in dpkg as
> an experiment before permitting it in the archive/policy.
>
> Jonathan

So far it is just an idea, unfortunately.

MfG
        Goswin


Reply to: