Bugzilla Bug 88924

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 an attachment (id=56144) [edit]
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 an attachment (id=56145) [edit]
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 an attachment (id=56168) [edit]
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 an attachment (id=56169) [edit]
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 an attachment (id=56180) [edit]
diff fo media-video/goggles ebuilds

Created an attachment (id=56181) [edit]
diff fo media-sound/rezound ebuilds

Created an attachment (id=56182) [edit]
diff for x11-misc/xfe ebuilds

Created an attachment (id=56257) [edit]
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 an attachment (id=56311) [edit]
diff for dev-util/freeride ebuilds

Created an attachment (id=56313) [edit]
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 an attachment (id=56489) [edit]
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 an attachment (id=56537) [edit]
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 an attachment (id=56552) [edit]
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 an attachment (id=56553) [edit]
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