Kurt Roeckx <k...@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 (r...@debian.org)               <http://www.eyrie.org/~eagle/>



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to