Re: dummy packages and "Replaces:" field
Margarita Manterola <margamanterola@gmail.com> writes:
> On 6/23/05, Steve Langasek <vorlon@debian.org> wrote:
>> > Well, a new header would be nice, of course. But it would mean a
>> > change in policy, that's why I was thinking of using the existing
>> > ones.
>> Changing the meaning of existing fields is far worse than changing policy to
>> accomodate a new field.
>
> Ok, agreed. So, if we had a new header to indicate that this is the
> "drop-in" replacement of the old program, it could work, right?
baz Conflicts/Replaces/Provides: foo
Then and only then can baz be installed automaticaly as upgrade of foo
(given that foo no longer exists).
> To achieve this change, we would need:
> * A policy change: include the new header and explain the meaning, in
> Section 7.
That would be much cleaner than using a combination of existing
headers to mean the same.
> * A change in dpkg's behaviour: interpret this header as a
> Replaces+Conflicts case, where all the files in the old package are
> replaced by the new package.
Replaces and Conflicts can still be used to express this. That way old
dpkg/apt can still install the new packages (but won't
automaticaly). That is rather important.
> * A change in apt/aptitude/synaptic/etc behaviour: install the
> program that has the new header when appropiate.
>
> It's a long way to go, I guess that it should start in dpkg, right?
>
> Which should this new header be?
> "Substitutes:", "Supersedes:", "Takes-Over:", "Drop-In Replaces:", "Follows:" ?
Supersedes sounds good.
MfG
Goswin
Reply to: