Changes to openvrml.spec

[Braden McDaniel]

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>