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

Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug [and 1 more messages]



Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

>> >> ------------------------+-----------------------+---------------------
>> >> Rename A to B           | optional make A       | Conflicts: A
>> >>                         | dummy/transitional    | Replaces: A
>> >>                         |   Depends: B          | Provides: A optional
> ...
>> Going the way of a dummy/transitional package is probably better than
>> the provides way. But I'm not sure there too. But one or the other can
>> be needed:
>
> Yes.  I think the transitional packages are usually better, but
> it seems that Provides is acceptable.  My proposed policy wording
> needs to be fixed.
>
>> Note: With a dummy/transitional package the Conflicts/Replaces in B must
>> be (<<) versioned I believe. Or should that be Breaks/Replaces then?
>
> Yes, it should be versioned Conflicts/Replaces as Jonathan points out.

Policy says Conflicts should always never be versioned. If
Conflicts/Replaces should be versioned then I think that should be
clarified more saying a lonely Conflicts shouldn't be versioned but a
Conflicts/Replaces combo should.

>> >> ------------------------+-----------------------+---------------------
>> >> Makes older A not work  | Breaks: B (<<)        | Breaks: A (<<)
>> >> but newer A is ok       | if it conflicted      |
>> >
>> > I'm not sure I follow your suggestion for A flags.  If what conflicted
>> > with what ?    I don't think anything should be needed in A.
>> 
>> Package: A
>> Versions: 1
>> Conflicts: B
>> 
>> Package: B
>> Versions: 1
>> Conflicts: A
>> 
>> ===>
>> 
>> Package: A
>> Versions: 2
>> Breaks: B (<< 2)
>> 
>> Package: B
>> Versions: 2
>> Breaks: A (<< 2)
>> 
>> If the old A conflicts with B then there is no way around updating A
>> along with B to make them coinstallable.
>
> How does the Breaks help here ?  It doesn't make the Conflict cease to
> have effect so yes if you have a system which has one of the old A or
> B you cannot install the other, even the new one, until you have first
> upgraded the one you have.
>
> Breaks relationships do not have to be symmetric, unlike Conflicts
> which are implicitly symmetric even though they are declared by only
> one of the packages.

The Breaks prevent the new A to be configured with the old B or new B
with old A. It also allows (hints even) any old A or B to be
deconfigured and then A and B can be upgraded/installed at the same
time. Unlike Conflicts it doesn't put such a constraint on the order the
packages are upgraded/installed.

MfG
        Goswin


Reply to: