Swig 1.3.22 includes *many* changes and enhancements over 1.3.21. I know almost nothing about ebuilds, but was able to modify the 1.3.21 ebuild to successfully build 1.3.22. I had to modify the SRC_URI to point to a specific sourceforge mirror, which I'm sure is a bad thing to do. But I couldn't get it working otherwise. The other two changes were to remove the build and install of the 'runtime' components, as these are now (apparently) deprecated by swig. (See the swig changelog entry "07/08/2004: wsfulton"). Kevin Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 39888 [details] swig-1.3.22.ebuild As I mentioned, this has a hard-coded sourceforge mirror, which is probably a bad thing.
hardcoded mirrors aren't good, why did you do that? please attach a patch instead of the complete ebuild
Created attachment 40095 [details, diff] Diff file from swig-1.3.21.ebuild to swig-1.3.22.ebuild Here is a patch against the 1.3.21 ebuild. Now, the only change is the removal of the deprecated runtime stuff. The first time I tried the original SF mirror, it failed. That's why I used a hard-coded mirror. Today, it worked with the original SRC_URI, so I removed that change. I have only tried emerging on x86, and have only tested the resulting swig executable for a ruby-based project.
i got many bugreports after removing the runtime stuff, so i think it should remain for now
ok, i see that runtime is no longer provided, so i removed it and commited swig-1.3.22
if the now-missing runtime bit is breaking things, how about package masking this build? or perhaps a depend line in here to prevent it from installing if any of the packages wanting runtime (like subversion) are already there? By not doing this, 1.3.22 gets installed, then on the next emerge world, subversion's requirement of 1.3.21 gets applied and swig is rolled back, then the cycle repeats...
