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

Bug#578854: Should "Conflicts" be added to the "Replaces" example for package splitting?



Stuart Prescott <stuart+debian@nanonanonano.net> writes:

> The discussion for #572253 has resulted in the following inclusion in
> policy (to be released as 3.8.5):

>>  	  <p>
>> +	    For example, if a package <package>foo</package> is split
>> +	    into <package>foo</package> and <package>foo-data</package>
>> +	    starting at version 1.2-3, <package>foo-data</package> should
>> +	    have the field
>> +	    <example compact="compact">
>> +Replaces: foo (&lt;&lt; 1.2-3)
>> +	    </example>
>> +	    in its control file.  The package <package>foo</package>
>> +	    doesn't need any special control fields in this example,
>> +	    although would generally depend on or
>> +	    recommend <package>foo-data</package>.
>> +	  </p>

> i.e. the example of "what to do when you split a package" only mentions
> that foo-data should have a versioned-Replaces on the pre-split
> packages.

> The discussion in #578854, however, seems to indicate that the
> preference is actually to use both a versioned-Replaces _and_ a
> versioned-Conflicts in this situation.

Thanks for pointing this out.  I think what this says is that we really
need to resolve #578854 for the next release.  I'm going to move this
discussion to that bug.

> Is my reading of the discussion in #578854 wrong? or would the following
> be a better example to include?

> 	Conflicts: foo (<< 1.2-3)
> 	Replaces: foo (<< 1.2-3)

This is definitely the current practice.

> Changing the example to this would mean that the example is in the wrong
> section and should appear in §7.6.2 not §7.6.1.

I'm not sure I understand why.  We're still talking about the case of
overwriting files from another package, which will remain installed, not
forcing removal of another package entirely.

One thing that I would like to explain in Policy, but for which I
personally don't know the reason and would like someone else to explain to
me first (*grin*), is why we use Conflicts along with Replaces here.  What
happens if one just uses Replaces (with a version stanza) and no
Conflicts?  What problem does adding the Conflicts correct?

My understanding of how Replaces works is that, provided that the new
foo-data package contains the same files as were in the foo package,
Replaces will allow it to simply overwrite those files, and there should
be no obvious reason to force an upgrade of the foo package.  Am I missing
something subtle, possibly around reinstallations or downgrades of foo?

> It also occurs to me that a concrete example of "how to split a package"
> like this is really good to have, but by the time it needs considerable
> explanation and additional fields added, it may actually start to
> distract from the purpose of policy and perhaps should be in
> dev-ref... but that's a completely different discussion again.

I think adding a complete example to devref is an excellent idea, but I
think we should have an example of at least the main fields one uses in
Policy directly, since that's the primary use case of some of these
fields.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: