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

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.


Reply to: