Hi Bob,
On Mon, 2012-06-18 at 10:27 -0400, Robert Kukura wrote:
> [I'm adding the fedora cloud list to this thread to solicit feedback on
> whether the Conflicts statement I've added to the latest rawhide
> python-quantumclient spec file is justified. I agree with Alan that
> Requires is preferred in general over Conflicts, but I'm not seeing how
> Requires could be used to resolve the issue. As background, note that
> the 2012.1 release of python-quantum had a dependency on the some
> "common" code that was provided by the 2012.1 release of
> python-quantumclient. This dependency did not exist in the 2011.3
> releases of these packages and will no longer exist in the 2012.2
> releases, so therefore I've asserted that the 2012.2 version (and
> higher) version of python-quantumclient conflicts with the 2012.1
> version python-quantum to prevent upgrading python-quantumclient from
> breaking python-quantum.]
>
> On 06/18/2012 07:31 AM, Alan Pevec wrote:
> >> +# The essex release of python-quantum dependend on
> >> +# python-quantumclient to provide %%{python_sitelib}/quantum, which is
> >> +# no longer provided. Users will have to upgrade both simultaneously.
> >> +Conflicts: python-quantum = 2012.1
> >
> > It is preferred to use Requires instead of Conflicts
> > http://fedoraproject.org/wiki/Packaging:Conflicts
>
> Alan, thanks very much for looking at this. If there is a better
> approach, I will fix this.
>
> I think the conflict is the only workable solution in this case. I'm
> trying to prevent an upgrade of python-quantumclient from essex (2012.1)
> to folsom (2012.2) from breaking an existing installation of essex
> python-quantum (2012.1). I can't go back and add "Requires
> python-quantumclient = 2012.1" to the python-quantum 2012.1 package,
> since there is no guarantee people would upgrade their essex
> installation of python-quantum before trying to upgrade to folsom
> python-quantumclient.
Firstly, I think it'd be worth doing some experiments to confirm the
actual behaviour of yum:
1) Without the Conflict you added, if you update quantumclient from
2012.1 to 2012.2 without updating quantum, does it really break
quantum? Why exactly?
2) With the Conflict you added, what happens if you try to update
quantumclient from 2012.1 to 2012.2? Just an error? It doesn't try
and force an update of quantum, does it?
In any case, I don't think the conflict is correct. There is no file in
quantumclient 2012.2 which conflicts with a file in quantum 2012.1.
In fact, it's the opposite - %{sitelib}/quantum in quantum 2012.2
"conflicts" with quantumclient 2012.1.
The issue you're trying to account for is just a packaging bug - quantum
2012.1 required %{sitelib}/quantum to be provided by another package and
rather than just expressing that as a file requirement, we expressed it
as a package requirement. By doing so, we were effectively saying that
part of quantumclient's contact is that it will always provide the
%{sitelib}/quantum directory.
So (bearing in mind this stuff is complicated and I could as easily be
wrong as anyone else) thoughts:
1) We should fix the packaging bug with a Fedora 17 update - i.e.
-Requires: python-quantumclient >= %{version}
+Requires: %{python_sitelib}/quantum/
2) Actually, maybe the correct solution should have been for both
2012.1 quantum and quantumclient to own the directory:
http://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function
Multiple packages can own the same directory and you shouldn't
require a package just for a directory it owns.
3) We don't need to add:
Conflicts: python-quantumclient = 2012.1
to quantum 2012.2 to handle the %{sitelib}/quantum conflict
because ... it's not a conflict since multiple packages can own the
same file.
to quantum 2012.2 since RPM knows about the file conflict without
any other help.
Summary - I think you should do a F17 update of python-quantum to have
it own %{sitelib}/quantum and remove the dependency on
python-quantumclient.
That doesn't handle the "I can't guarantee people will update their
2012.1 python-quantum before updating their 2012.2
python-quantumclient", but more on that below ...
> I think this usage is justified under the clause: "Keep in mind that
> implicit conflicts are NEVER acceptable. If your package conflicts with
> another package, then you must either resolve the conflict, or mark it
> with Conflicts:." The implicit conflict does exist, since the upgrade of
> python-quantumclient to 2012.2 would remove stuff the 2012.1 version of
> python-quantum depends on.
I don't think that's a conflict, that's a poorly expressed dependency.
What I take away from this page:
http://fedoraproject.org/wiki/Packaging:Conflicts
is that the Conflicts tag is often misunderstood and/or misused, that
the package committee's experience is that it's often not what you want
and that you should talk to them if you want to use it for anything
other than the "optional functionality" and "compat package" cases.
If you're not persuaded by my suggestions, there's no harm at all in
asking for their advice. In this case, I expect they might say
"Conflicts isn't a tool for retroactively fixing packaging bugs" but
they could easily have a completely different perspective.
Cheers,
Mark.
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
