On Mon, Jun 18, 2012 at 4:27 PM, Robert Kukura rkukura@redhat.com wrote: ...

On 06/18/2012 07:31 AM, Alan Pevec wrote:

...

What about this: folsom version of python-quantum should have Requires: python-quantumclient >= 2012.2 and here in python-quantumclient Requires: python-quantum >= 2012.2

The whole point of the upstream change was to decouple python-quantum and python-quantumclient. In folsom, neither depends on the other upstream, so I'd strongly prefer not to have either folsom fedora package require the other.

Any other ideas? I did include an explanation in the spec file as required by the packaging guidelines when the conflicts is used. Or is this OK?

If you don't want new python-quantumclient to have a hard dependency on python-quantum, they, yeah, there isn't other way than conflict. Otherwise, Requires as I proposed should produce the same result after yum update.

I'd like to use the opportunity to discuss what is everybody's expected behavior on upgrade when upstream splits or reorganizes. I'd like to ensure "least surprise" for the user i.e. yum update should produce a system with the same functionality.

For example, in Swift 1.5.0 S3 emulation was removed from the core and split as a new plugin project http://github.com/fujita/swift3 When packaging this, I made openstack-swift require new package openstack-swift-plugin-swift3 otherwise user would be left w/o S3 emulation. Of course, configuration files (or rather paste-deploy which is more code than config) need to be edited, replacing egg:swift#swift3 with egg:swift3#swift3 but we don't have a solution for that in RPM-world, except to provide .rpmnew and leave to the administrator to merge configuration changes. Best would be if all paste-deploy is moved out of files marked %config and located under /usr/share/ where it can be safely updated.

Cheers, Alan