Bug#578854: New workding for Conflicts, Breaks, and related sections

[Russ Allbery <rra@debian.org>]

Kurt Roeckx <kurt@roeckx.be> writes:
> On Wed, Jun 16, 2010 at 11:07:33AM -0700, Russ Allbery wrote:

>>  	<p>
>>  	  Normally a <tt>Breaks</tt> entry will have an "earlier than"
>>  	  version clause; such a <tt>Breaks</tt> is introduced in the
>> -	  version of an (implicit or explicit) dependency which
>> -	  violates an assumption or reveals a bug in earlier versions
>> -	  of the broken package.  This use of <tt>Breaks</tt> will
>> -	  inform higher-level package management tools that broken
>> -	  package must be upgraded before the new one.
>> +	  version of an (implicit or explicit) dependency which violates
>> +	  an assumption or reveals a bug in earlier versions of the broken
>> +	  package, or which takes over a file from earlier versions of the
>> +	  broken package.  This use of <tt>Breaks</tt> will inform
>           ^^^^^^
>> +	  higher-level package management tools that broken package must
>> +	  be upgraded before the new one.
>>  	</p>

> The word broken there might be a little missleading, since nothing
> broken, and it's just used to force an upgrade of the other package.

Changed to "the package named in <tt>Breaks</tt>".

>> +	  breakage).  In other words, if a version number is specified,
>> +	  this is a request to ignore all <tt>Provides</tt> for that
>> +	  package name and consider only real packages.  The package
>> +	  manager will assume that a package which package which provides
>                                              ^^^^^^^^^^^^^

> That should probably be removed.

Good catch, thanks.  Reworded.

>> +	  Normally, <tt>Breaks</tt> should be used in conjunction
>> +	  with <tt>Replaces</tt>.<footnote>
>> +	    To see why <tt>Breaks</tt> is required in addition
>                                           ^^^^^^^^

> That's probably a too strong word, specially since you have a
> should there.

Changed to "normally needed."

>>  	  <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
>> +	    starting at version 1.2-3, <package>foo-data</package> would
>> +	    have the fields
>>  	    <example compact="compact">
>>  Replaces: foo (&lt;&lt; 1.2-3)
>> +Breaks: foo (&lt;&lt; 1.2-3)
>> +	    </example compact="compact">
>> +	    in its control file.  The new version of the
>> +	    package <package>foo</package> would normally have the field
>> +	    <example>
>> +Depends: foo-data (&gt;= 1.2-3)
>>  	    </example>

> I'm not sure what it does exactly, but you've created one example
> with compact, the other without.  And closing the example probably
> doesn't need to set the compact.

Yeah, added the attribute to the wrong line.  Fixed.

> I can see why which this breaks in the "foo-data" package is useful, but
> find it non-obvious, and currently see no beter way to get the same
> behaviour.

The non-obviousness is one of the reasons why I wanted to be sure to
document it, since I'd never understood this personally.

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