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 attachment 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 attachment 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 attachment 14279 [details, diff] Patch required by aldumb-0.9.2.ebuild ... and here's the patch.
Created attachment 14280 [details, diff] 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 attachment 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!