Re: Conflict field for logical conflicts?
Jörg Sommer <joerg@alea.gnuu.de> writes:
> Hi,
>
> should I set in package jed a conflict on a package jed-extra if
> jed-extra enhances jed, but jed has changed its API and now jed-extra is
> useless, i.e. it must be updated. jed-extra and jed can be installed at
> the same time without harm, but jed-extra does not enhance jed anymore,
> because it's not (directly) accessable from jed.
>
> It's like a new API in firefox and the firefox-webdeveloper extension.
> Should firefox declare a conflict on all extensions if the API changes or
> is this a problem of the extension package?
>
> Should an entry in the conflict field describe such a logical conflict or
> only a conflict on the package/library level which prevents the packages
> can't be installed?
>
> Bye, Jörg.
What you want is:
jed: Provides: jed-abi-23
jed-extra: Depends: jed-abi-23
You should add such a provides in jed now and update the jed-extra
package asap. The next time the ABI changes you bump the provides. If
the ABI only extends the old one then "Provide: jed-abi-23,
jed-abi-24".
The advantage of this is that you don't create a depends/conflicts
loop and prevent upgrades that break stuff. Users of jed-extra will
have jed "kept back" untill jed-extra is updates to the new jed abi
when that changes. Both packages will also enter testing as a pair.
But you didn't do that so now you have some fixing to do (imho):
You can't change existing packages so any change has to be done in new
uploads.
Since the new jed breaks the old jed-extra:
jed: Conflicts: jed-extra (<= old version).
Since the (soon to be) new jed-extra doesn't work with the old jed:
jed-extra: Depends: jed (>= new version). [abi provide preferable
though].
MfG
Goswin
Reply to: