Re: [python-quantumclient] Add conflict with python-quantum 2012.1 since site-packages/quantum is no longer provided.
9:27 a.m.
[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.
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.
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?
Thanks,
-Bob
Alan
2:53 a.m.
New subject: [python-quantumclient] Add conflict with python-quantum 2012.1 since site-packages/quantum is no longer provided.
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...
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.
4328
days inactive
4329
days old
1 comments
2 participants
participants (2)
-
Mark McLoughlin -
Robert Kukura