Comment # 6 on bug 962599 from Dominique Leuenberger

(In reply to Matwey Kornilov from comment #5)
> We don't lose anything except somebody will send erlang-rebar again
> eventually, because it is the most popular build system for erlang.
> 
> So, is "Prefer: erlang-rebar-obs" acceptable solution?
> If so, there are not so many thing to redo.
> 
> erlang-rebar-obs will provide erlang-rebar, and Prefer will force conflict
> resolution.

Prefer: is the way it's done in all other cases - and the resulting -mini (or
-obs in your case) is not installable by zypper due to the missing dep
'this-is-only-for-buildsystem'. But IIRC a Provides: erlang-rebar won't work,
as OBS will automatically already prefer the actual package with that name over
a virtual provides.

As far as I see, the difference between erlang-rebar-obs and erlang-rebar is
actually no BUILD difference, but wether the test suite is executed or not?
Then I'd argue the entire setup is overcomplicated.

I'd suggest to think about a solution like (similar to gcc):

erlang-rebar
with a 2nd spec file erlang-rebar-testsuite (preferably not rebuilding the
whole thing, but reusing what was there in first place)

then, erlang-retest can properly depend on erlang-rebar, and
erlang-rebar-testsuite can depend on erlang-rebar (for whatever built stuff it
wants to test) and erlang-retest.

That should give a clean dependency tree and if we're lucky, even not require
to do two builds of the same source (currently, erlang-rerbar and
erlang-rebar-obs both build the same sources.