Changes to openvrml.spec
Braden McDaniel
braden at endoframe.com
Sun Sep 13 02:49:06 UTC 2009
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.
--
Braden McDaniel <braden at endoframe.com>
More information about the fedora-devel-list
mailing list