The problem is thus: each minor version number of fox has an incompatible API, but (thankfully) is made to install in parallel, except that each version comes with the same applications, which don't change as much, except to keep with the API version their packaged with. Now, for example, fxscintilla will work with either fox-1.0 or 1.2, FXPy needs fox-1.0, FXRuby-1.2 (used by dev-util/freeride) needs fox-1.2 and fxscintilla for fox-1.2, but FXRuby-1.0.29 needs fox-1.0 with fxscintilla for fox-1.0 (and these two can be installed in parallel), foXdesktop[1] (not currently in portage) needs fox-1.4. Currently, there is no way to merge all of these at once, which is obviously not the Gentoo way. The solution: have x11-libs/fox install just the headers, libs, and (depending on USE flags) docs into different SLOTs, and break out the applications into separate (all SLOT="0") ebuilds. Then, go through portage and make sure that everything dependent on fox DEPENDs on only the SLOT it needs. I've done the first part by creating a fox.eclass which handles building fox itself and the apps from the fox tarball in separate ebuilds, namely: app-editors/adie dev-util/reswrap sci-calculators/calculator x11-misc/pathfinder x11-misc/shutterbug I've made ebuilds for all of the above, plus x11-libs/fox, which inherit the fox.eclass to do the work for them. The ebuilds comprise patch-level version bumps for each SLOT: 1.0.53 (slot 0), 1.2.15 (slot 1.2), 1.4.12 (slot 1.4), and a devel branch 1.5.3 (slot 1.5, to be p'masked if you import it yet). The ebuilds themselves are pretty small, leaving the work to fox.eclass to build, install, and SLOT and symlink the fox-config scripts. Fixing fxscintilla for the multiple SLOTs was a bit of a challenge; in the end, I borrowed from wxGTK, which also installs several APIs from the same ebuild. So, fxscintilla DEPENDs on both fox-1.0 and fox-1.2, and builds separate libs for each API. Then, dev-python/fxpy was a matter of fixing deps, plus a small unrelated patch (since we now use econf and hence respect EXTRA_ECONF, the only library file we can count on being present is libFOX.la). dev-ruby/fxruby-1.0 and 1.2 can now also be SLOTted (fox.so and fox12.so), with corrected deps. I bumped both fxpy and fxruby to catch these changes. What's left is to correct the remaining packages in the tree that DEPEND on x11-libs/fox, namely: dev-util/freeride media-sound/rezound media-video/goggles x11-misc/xfe DEPENDs on fox must *ALWAYS* (irrespective of this work) be in the form of '=x11-libs/fox-1.2*', or if necessary, '>=x11-libs/fox-1.0.17 <x11-libs/fox-1.1'. The above ebuilds (except for xfe?) incorrectly DEPEND, for example, on '>=x11-libs/fox-1.2', which portage will think is provided by 1.4 when in reality it won't work. AFAICS all current fox ebuilds >=1.2 (which aren't SLOTted) will need to be p.mask'ed and then removed to avoid interfering with this. I'm attaching a tarballed overlay which contains the eclass and ebuilds for fox, its apps, fxscintilla, fxpy, and fxruby. If there's something that needs clarification please feel free to ask; I believe, however, that I covered all the bases with this work. I hope you find this helpful. [1] http://foxdesktop.sourceforge.net/
Created attachment 56144 [details] tarball of fox overlay I know it's generally undesirable to attach tarballs, but there's too many files involved to post one at a time. Sorry for the inconvience.
Created attachment 56145 [details] fox.eclass Well, since this is the core of the work, I'll attach this separately as well; it's the same file as included in the tarball.
Created attachment 56168 [details] fox-overlay.tar.bz2 Take two. After further testing, I saw that creating symlinks for fox-config was at best unreliable. So instead, I made x11-libs/fox-wrapper, which makes /usr/bin/fox-config a symlink to a wrapper script, similar to automake-wrapper. I believe that this a better solution and is working properly. The only catch is to check the other apps which DEPEND fox and see if their builds call fox-config directly; if so, an 'export WANT_FOX="1.?"' will need to be added to their ebuilds. Also, about dealing with the current fox ebuilds, even the existing 1.0 builds will be a problem with collision-protect, as dev-util/reswrap will collide with whichever fox currently installed. BTW, besides the apps noted above which DEPEND fox directly, the following DEPEND fxruby: dev-util/freeride net-irc/xdcc-fetch AFAICS nothing in portage DEPENDs fxpy.
Created attachment 56169 [details] fox.eclass Here's the revised eclass, which is also in the tarball.
I filed bug 88983 to get newicon into eutils and out of the fox.eclass.
Created attachment 56180 [details, diff] diff fo media-video/goggles ebuilds
Created attachment 56181 [details, diff] diff fo media-sound/rezound ebuilds
Created attachment 56182 [details, diff] diff for x11-misc/xfe ebuilds
Created attachment 56257 [details] fox.eclass Looks like I slipped in a last-minute typo in the eclass. This *supersedes* the eclass in the tarball.
Looks like some nice work. I'll commit this soon.
Created attachment 56311 [details, diff] diff for dev-util/freeride ebuilds
Created attachment 56313 [details, diff] diff for net-irc/xdcc-fetch ebuilds I think that's everything now, short of waiting for bug 88983. Here are the affected package maintainers/herds, based on current metadata.xml: dev-python/fxpy: python dev-ruby/fxruby: ruby dev-util/freeride: ruby media-sound/rezound: sound media-video/goggles: video net-irc/xdcc-fetch: net-irc x11-misc/xfe: s4t4n desktop-misc
Created attachment 56489 [details] fox.eclass newicon is now in eutils.eclass. I also added to pkg_postinst an einfo about the separate ebuilds for reswrap and the apps.
Created attachment 56537 [details, diff] diff for media-video/goggles ebuilds This is an updated patch for goggles due to a change in 0.8.0-r1, which also uses domenu and newicon (not related to this really, but while I was at it...)
Created attachment 56552 [details] fox.eclass Take five. Learned something new today... I saw on the fox-users list that doxygen can be used to build class reference docs for FOX >=1.2. This new ebuild handles that as well.
Created attachment 56553 [details] fox-overlay.tar.bz2 This overlay includes the newest eclass from comment 15, plus version bumps to the 1.5 devel branch (1.5.3 -> 1.5.4) and fxruby (1.2.6).
Most of the ebuilds have been committed and masked for testing.
Looks like you made an x11-misc/pathfinder directory, but there's no files there, and you didn't include sci-calculators/calculator. I assume that's what you mean by "most". Just curious, are there any issues with those ebuilds in particular?
Yaakov... Are you getting repoman errors within the pathfinder directory? What is causing them?
Never mind comment 18. Everything looks good now. FYI, there are bumps to 1.2.16, 1.4.16, and 1.5.5 upstream; haven't had a chance to test them though.
How's going? I currently can't emerge FXRuby because of exactly the problems mentioned in the motivation. Any solution on the horizon?
These ebuilds were committed to the portage tree on 07 May 2005, but are still p.mask'ed and ~arch. You'll need to add these packages to package.unmask and package.keywords in order to emerge them (you can find the full list of fox packages in profiles/package.mask, entered on the aforementioned date.
Hello, Has this evolved in any way? I can not help but notice that fox, fxruby, and fxscintilla are quite out-of- date even in the hardmasked ones. I would like to know if this nice idea is frozen, and I'd better update the ebuilds on my own, or somebody else is working on it. (I need to use fxruby 1.4.x, which is not in Portage yet)
So... what's the shortest way to install FreeRIDE ?
Try 'emerge dev-util/freeride' :-) http://packages.gentoo.org/packages/?category=dev-util;name=freeride
(In reply to comment #25) > Try 'emerge dev-util/freeride' :-) > http://packages.gentoo.org/packages/?category=dev-util;name=freeride Even FreeRide 0.9.4 ? I have compile problems at fxScintilla emerge time :-(
Is this moving forward at all? I only ask, because since I've upgraded to GCC4 I'm unable to use fxruby and fox with the version of ruby I do have (even though fxruby 1.6 and fox 1.6 are released). I'm sure others are experiencing the same issue, and am wondering if there is a work around at the moment to be able to get these working again?
The Gentoo developer who originally managed the fox packages (i.e. the previous bug owner) has retired, hence no progress has been made. The versions in this overlay need to be updated. If you're having problems since upgrading GCC, you probably need to rebuild; see the GCC migrating guide for details.
I'll take a look and report back once i have something working. From what i can see now, we need to drop fxruby-1.2* b/c it doesn't compile with GCC4.1 and upstream isn't accepting fixes anymore (no time to fix it myself, any patches?) I'd like to bring the -1.4 and -1.6 stable branches up2date and provide the development -1.7 branch. Lets see what i can come up with.
> From what i can see now, we need to drop fxruby-1.2* b/c it doesn't compile > with GCC4.1 and upstream isn't accepting fixes anymore (no time to fix it > myself, any patches?) That will mean masking dev-util/freeride as well, as the latest version still uses fxruby-1.2. Providing fxruby-1.6 (is anything using it yet?) will also need a CVS build of fxscintilla. I'm just getting my Gentoo box running again after quite a while, but I'll try to help as I can.
I've just committed two new versions of fxruby to the tree. I'm unsure about the status of freeride though, my last test run yielded quite scaring 'invalid header format (i686)' warnings for the binarys and i'm looking into it (ruby herd?).
So last issue is a unusable freeride. I'm getting me the sources and try to stitch it together with fxruby-1.6, as that is what all arches have stable now. Freeride is abondoned upstream as of yesterday, but i still will try to solve the issue. The stale fxruby-1.2 ebuilds are gone, sorry, it was high time for them.
(In reply to comment #32) > Freeride is abondoned upstream as of yesterday No, it seems to be still alive ! :) See http://rubyforge.org/pipermail/freeride-devel/2007-June/000594.html
This was "fixed" with the removal of freeride in bug #251935 Everything else was dealt with by upgrading.
