Bugzilla Bug 23464

DUMB consists of two parts: a core that generates music, and an optional
interface with Allegro that can send the music through Allegro's sound output
system. Most people using DUMB use both (but not all, for instance DUMB-XMMS
doesn't use Allegro).

DUMB v0.9.1's ebuild depended unconditionally on Allegro, and always compiled
the Allegro interface.

DUMB v0.9.2's ebuild (submitted by me) does not depend on Allegro unless the
(local) use flag 'allegro' is set. If you want the Allegro interface to be
compiled, you need to do `USE="allegro" emerge dumb`.

There is at least one ebuild (app-games/raptor2) that depends on >=dumb-0.9.1
and requires the Allegro interface. I have not tried to install this (mainly
because as DUMB's developer I have installed CVS manually rather than using the
ebuilds), but I know it will fail on systems with ACCEPT_KEYWORDS="~x86" because
DUMB's Allegro interface won't be built.

Here are the solutions I am aware of, and associated problems:

- Split DUMB into two ebuilds, one that does the core and one that does the
Allegro interface. Tricky, because DUMB comes in one package, and stuff may end
up being built twice.

- Always build the Allegro interface. But then Allegro is a dependency, and
Allegro takes ages to compile. Software like DUMB-XMMS that doesn't require
Allegro would then take ages to install and pull unnecessary stuff into the system.

- Is it possible to force use flags in a dependency? If so, how do we do this?
Something makes me think this isn't possible because then the package would have
to reinstall if the USE flags changed one way but not if they changed the other,
or whatever ...

If the last-mentioned solution is possible, I'd like to change DUMB's ebuild so
that you specify a USE flag if you DON'T want Allegro set up. But it may be
academic.

I'd like to hear some opinions from those who know ebuilds inside out, but if no
one has any suggestions I'll work on the first solution. So, any suggestions?

There is no way to specify a use flag in a DEP. So, we can't really win here.
We have DEP which want it both ways (XMMS vs Most other things depending on
DUMB).

It would have to be done upstream by you I think, and then split into two
ebuilds here. Or something..

Messy :/

Hmm. Oops. Just to clear up some misinformation for those browsing this bug
report, you actually need to do: USE=dumb-allegro emerge dumb
No one told me about this when the ebuild was committed :P

Anyhow, I think it should be possible to build only the Allegro interface part
of DUMB without the core being built. Of course it wouldn't be usable, but it
should compile. That means it may be feasible to split it into two ebuilds
without incurring too much extra work. I also noticed that emerge keeps the
packages around, so it won't even have to download it twice. Yippee \o/

So I'll start working on that sometime soon.

Created an attachment (id=14277) [details]
New ebuild; does DUMB's core alone

This ebuild goes in media-libs/dumb and does DUMB's core alone. It no longer
leverages the dumb-allegro USE flag; this can be removed from use.local.desc as
soon as dumb-0.9.2.ebuild is removed from portage. (There is no rush to remove
this old ebuild, since it will function the same as the new one as long as no
one tries to use the old USE flag.)

Created an attachment (id=14278) [details]
New ebuild: does DUMB's Allegro support alone

This ebuild, to go in media-libs/aldumb, does DUMB's Allegro support, and
suitably depends on 'dumb' and 'allegro'. A small patch to DUMB's Makefile was
necessary so that DUMB would link the example program with the already
installed core instead of rebuilding the core for use by the example program.
Yay. See below ...

Created an attachment (id=14279) [details]
Patch required by aldumb-0.9.2.ebuild

... and here's the patch.

Created an attachment (id=14280) [details]
Change to the existing ebuild for the game Raptor

Raptor (app-games/raptor2) is the only game in the portage tree that uses DUMB
- unless others have been submitted very recently. If they have, I daresay I'll
find them when I do a bug search :)

This patch modifies the existing ebuild so that it will require DUMB v0.9.1, no
more, no less. This is because the DUMB v0.9.1 ebuild always builds Allegro
support, and the DUMB v0.9.2 ebuild does not. Since raptor2-1.0.0 and
dumb-0.9.1 are both marked as stable, and dumb-0.9.2 is marked as unstable, I
think it's wise to make this change. I also have a new raptor2 ebuild revision,
which I will attach in a moment ...

Created an attachment (id=14281) [details]
Raptor update - this one is for DUMB v0.9.2

Here's the new ebuild for Raptor 2. It depends on aldumb-0.9.2, which in turn
depends on dumb-0.9.2-r1.

There, all done! I don't see any need to revise the DUMB-XMMS ebuild to depend
on dumb-0.9.2-r1 or greater. DUMB-XMMS may be built with dumb-0.9.2, but this
ebuild doesn't do the Allegro support by default so I don't see a problem. :)

Hmm, OK, it seems Bugzilla stripped the filenames. In order of attachment, the
filenames should be:

media-libs/dumb/dumb-0.9.2-r1.ebuild
media-libs/aldumb/aldumb-0.9.2-r1.ebuild
media-libs/aldumb/files/aldumb-0.9.2.Makefile.patch
patch to be applied to: app-games/raptor2/raptor2-1.0.0.ebuild
app-games/raptor2/raptor2-1.0.0-r1.ebuild

Just to say, all the ebuilds have been tested.

D'OH! The second file should be named:

media-libs/aldumb/aldumb-0.9.2.ebuild

without the '-r1'. Oops :)

k. I think i've finally got my head around this and will attempt to commit it
all. You may well be hearing pleas for help from me... :-)

Commited. Let me know if i missed anything.

Thanks for the update!