The ebuild needs a version bump. I would also suggest that the ebuild is broken into several ebuilds (one for each component and geda depending on them). Reproducible: Always Steps to Reproduce: 1. 2. 3.
According to the attached url, geda does not need half of the depencies it currently depends on. I'm going to post a proposed ebuild w/o them (as soon as I get it to compile clenaly on my system).
Created attachment 69758 [details] sci-libs/libgeda/libgeda-20050820.ebuild libgeda-20050820 (needed by geda-20050820)
Created attachment 69759 [details] sci-electronics/geda/geda-20050820.ebuild geda ebuild. Take notice of the difference on the dependencies from geda-20050313.
The files for both ebuilds should be downloaded from : http://www.geda.seul.org/download.html#sources The makefile should be renamed geda-20050820.Makefile
Sure would be nice to see this stuff in portage. I've also been rather disturbed by the enormous number of unneccessary dependancies in this package. Not everybody who wants gschem also wants verilog, and it is not truly a dependancy (geda compiles and installs just fine without it). Ditto for gtkwave, ngspice, etc. Also, ~amd64 should be added to geda, libgeda, and libgdgeda. I have just successfully installed all three on my amd64 system, using the ebuilds attached here, and manually adding amd64 in my local overlay. (I did not try with the current ebuilds in portage, since there are WAY too many dependancies, most of which are neither ~amd64 nor amd64.) This is the first time I have successfully gotten geda running on my system outside of a 32-bit chroot, and I am VERY excited about that.
Randall - regarding the dependency mesh (i.e. iverilog, etc.) I used the EDA list gEDA provides on their download page... a reasonable solution to this would be to possibly have a local USE flag of some sort (maybe 'edatools' or something) which if not turned on would not pull in gerbv, gnucap and all those other tools. Does this sound reasonable? As for splitting gEDA itself up into geda- components I think the idea isn't too suitable as you really do want all the geda- components together... having them split out would only make maintainance hell since a large set of ebuilds would have to be changed rather than one (and upstream releases the whole thing as a big set anyway)...
*** Bug 107924 has been marked as a duplicate of this bug. ***
Randall, I've made this version bump because I couldn't get the last version compiling on my AMD64 machine (since I refuse to build a 32bit chroot :) ). It seems to be working without a glitch here. And yes, I have the same problem as you, I only need gschem, and was forced into all the depencies of the old ebuild (some of them do not like amd64 nor gcc4.* ).
A USE flag for the extra components would be a good step, but perhaps use a metapackage instead? gEDA itself could become geda-core, which would be only the gEDA components, then have a metapackage that depends on the entire EDA suite (geda-suite, or just geda). I agree that it would be a pain to maintain separate geda-* ebuilds for each component of geda, but I think the above scheme to handle the auxiliary tools would be helpful, or else the USE flag solution is also fine I guess. (Though it is my impression that USE flags are for customizing the compilation, not for bringing in dependancies for extra components that aren't actually part of the compilation.)
Bumped in CVS, deps cleaned up and sci-electronics/geda-suite added. Thanks!
