You (spot) said:
"undo arch-specific deps on gecko-libs and java (%%{?isa} doesn't work like you think it works)"
Unless I was told the wrong things in this thread:
https://www.redhat.com/archives/fedora-devel-list/2009-July/msg01366.html
... it *does* work like I think it works. xulrunner and openjdk are broken.
AFAICT, no one who's actually looks at this disputes that the aforementioned packages are broken. There is some resistance to fixing them (for reasons I do not entirely agree with).
As it stands, though your changes fix a dependency problem, they make the specfile less correct and openvrml is susceptible to the problem documented in the aforementioned fedora-devel thread. It would be better if xulrunner and openjdk were fixed instead (bugs 517665 and 517666, respectively).
On 09/12/2009 05:45 PM, Braden McDaniel wrote:
... it *does* work like I think it works. xulrunner and openjdk are broken.
So, here's the deal.
The only Provides which automagically get %{isa} appended to them are the package name autogenerated provides. So, in this spec snippet:
Name: foo Version: 0.1 Release: 1 Provides: bar = 0.2
It is only safe to assume that "foo%{isa}" exists as a Provide.
Now, if your package needs to use "bar%{isa}" as a Provide, you can ask the maintainer of the foo package to add an additional Provide:
%if 0%{?isa} Provides: bar%{isa} = 0.2 %endif
If and when they do so, then (and ONLY THEN) is it appropriate for you to have:
Requires: foo%{isa}
in your package.
In the specific case of openvrml, NOTHING currently provides either "gecko-libs%{isa}" or "java%{isa}", thus causing the openvrml to be wholly broken and uninstallable. This is why I dropped the %{isa} off of them in rawhide.
I know that you have filed bugzilla tickets with xulrunner and openjdk to add these additional provides, and when they make this change, it is perfectly acceptable for you to update the openvrml Requires accordingly. It is not however, acceptable to leave openvrml in an uninstallable state while you wait for those tickets to be resolved.
(Alternately, there may be merit in lobbying upstream RPM to append %{isa} automagically to all non-file provides (as an additional provide, not as a replacement), but I don't know what they will think about that.)
Hope that clarifies things here,
~spot
On 09/12/2009 07:05 PM, Tom "spot" Callaway wrote:
If and when they do so, then (and ONLY THEN) is it appropriate for you to have:
Requires: foo%{isa}
Ugh, this should be:
Requires: bar%{isa}
(as I pointed out, foo%{isa} will always work in modern Fedora (F10+)).
Sorry for the confusion.
~spot
On Sat, 12 Sep 2009 19:10:35 -0400 "Tom "spot" Callaway" tcallawa@redhat.com wrote:
On 09/12/2009 07:05 PM, Tom "spot" Callaway wrote:
If and when they do so, then (and ONLY THEN) is it appropriate for you to have:
Requires: foo%{isa}
Ugh, this should be:
Requires: bar%{isa}
(as I pointed out, foo%{isa} will always work in modern Fedora (F10+)).
Sorry for the confusion.
And you probably mean %{_isa} rather than %{isa} too.
Paul.
On Sat, 2009-09-12 at 19:05 -0400, Tom "spot" Callaway wrote:
On 09/12/2009 05:45 PM, Braden McDaniel wrote:
... it *does* work like I think it works. xulrunner and openjdk are broken.
So, here's the deal.
The only Provides which automagically get %{isa} appended to them are the package name autogenerated provides. So, in this spec snippet:
Name: foo Version: 0.1 Release: 1 Provides: bar = 0.2
It is only safe to assume that "foo%{isa}" exists as a Provide.
Now, if your package needs to use "bar%{isa}" as a Provide, you can ask the maintainer of the foo package to add an additional Provide:
%if 0%{?isa} Provides: bar%{isa} = 0.2 %endif
If and when they do so, then (and ONLY THEN) is it appropriate for you to have:
Requires: foo%{isa}
in your package.
I made the change before it was apparent that the arch-specific Provides weren't being generated. At the point that became clear, it seemed to make sense to me to fix the Real Problem: as it stands, it is impossible for downstream packages to articulate the correct Requires.
In the specific case of openvrml, NOTHING currently provides either "gecko-libs%{isa}" or "java%{isa}", thus causing the openvrml to be wholly broken and uninstallable. This is why I dropped the %{isa} off of them in rawhide.
I know that you have filed bugzilla tickets with xulrunner and openjdk to add these additional provides, and when they make this change, it is perfectly acceptable for you to update the openvrml Requires accordingly. It is not however, acceptable to leave openvrml in an uninstallable state while you wait for those tickets to be resolved.
The change you made results in something that stops generating e-mail, yet remains incorrect and can in some situations successfully install something that doesn't work.
I'm afraid it's not glaringly obvious to me how much of a win that is.