Margarita Manterola <[EMAIL PROTECTED]> writes: > On 6/23/05, Steve Langasek <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]