Re: Conflict field for logical conflicts?
Hamish Moffatt [EMAIL PROTECTED] writes: On Sun, Jun 11, 2006 at 07:39:55PM +0200, Goswin von Brederlow wrote: 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. Great idea, but it doesn't work due to #170825. dpkg allows jed to be upgraded even though it breaks jed-extra. Hamish But that is dpkgs fault and someone seems to be working on it (or was in May). Does apt-get actualy suffer from the same problem or does it correctly keep jed as kept back? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflict field for logical conflicts?
Hi,
Jörg Sommer wrote:
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?
AIUI it's a problem with jed-extra and should be solved there. I suggest to
update jed-extra to the new jed API or at least file a bug requesting this
update.
The thing you tried to express in jed's dependencies could be expressed
easier and more correctly in jed-extra's dependencies:
Depends: jed (= ${last_compatible_version})
Yours
Micha
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflict field for logical conflicts?
Jörg Sommer [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflict field for logical conflicts?
On Sun, Jun 11, 2006 at 07:39:55PM +0200, Goswin von Brederlow wrote: 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. Great idea, but it doesn't work due to #170825. dpkg allows jed to be upgraded even though it breaks jed-extra. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Conflict field for logical conflicts?
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. -- Eine Blume geht über eine Wiese, sieht einen schönen Menschen und reißt ihm den Kopf ab. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
