Packaging upstream splits/reorgs WAS Re: [python-quantumclient] Add conflict with python-quantum 2012.1...

[Alan Pevec]

On Mon, Jun 18, 2012 at 4:27 PM, Robert Kukura <rkukura at 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