So I'm trying to figure out the best way to integrate Gentoo Ebuilds
and 0install.  Hopefully this will get the discussion off my beautiful
http://rox.sourceforge.net/desktop/Gentoo page :)

As far as I can see, there are a number of minor issues regarding
0install that prevent it from playing along well with Gentoo's ebuilds:

First Issue: Removing code duplication by improving local feed support
============

When 0install is installed just in a single user's account, there
is no easy way to automatically check what packages are installed
locally without manually adding a local feed, and even then the remote
feed may be more up-to-date than the local feed, forcing an extra
download of software that's already present.  For example, the latest
released ROX-Lib2 tarball has:

<group main="AppRun">
    <implementation id="." released="2006-05-28" stability="testing" version="2.0.3"/>
</group>

Whereas the remote feed has:

<implementation id="sha1=6a2e548a80368bd8c2b5b3abedccf9a0a6cb4333" version="2.0.3" released='2006-06-03'>
      <archive extract="rox-lib2-2.0.3"
href="http://kent.dl.sourceforge.net/sourceforge/rox/rox-lib2-2.0.3.tar.bz2" size="127605"/>
</implementation>

While the version numbers are the same, the 'released' timestamp of the
remote feed is newer, and only the local feed is marked as "testing".

I would suggest that the solution to this is twofold:

- There should be some way that 0install can automatically search for
and add local feeds in a set of paths, preferably a list of paths set in
the environment.

- When upstream moves a package from 'testing' to 'stable' they should
not just update the .xml file, but also release a new tarball with a
new version number (and the new .xml file for local feeding), or perhaps
use a scheme of naming the tarballs such that the version number stays
the same, but the 'testing' versus 'stable' status is reflected some
other way, for example by suffixing the version number with '_beta' in
the case of a testing release.

Second issue:  What about when 0install is installed globally
=============

I have not been able to replicate this locally yet, but it was
reported by one user that when 0launch is available globally, very
strange problems started happening when they tried emerging 'clock':

First the configure process tried to call 0launch to download a new
rox-clib.  This is in part due to the first issue above (rox-clib
installed from a tarball will always seem 'older' than the remote feed).
But the real problem here was that the call to 0launch goes interactive
(ie, requires user input, or may even pop up a window if DISPLAY is set)
which is a BIG no-no in an ebuild.

To get around this, I now do a small check to see if configure.in uses
the ROX_CLIB_0LAUNCH(...) macro and replace it with ROX_CLIB(...) which
will just check all normal local paths, which should be okay.

I suppose a more proper fix would be to change the ROX_CLIB_0LAUNCH
macro (and others like it, if there are any) to accept a configure flag
like '--disable-0launch' which would disable calling 0launch altogether.

Secondly he had problems when actually trying to run Clock, but I think
this was due to his LIBDIRPATH environment set up wrong somehow - It
couldn't find rox-clib even though it was just in /usr/lib which is
normally searched by LIBDIRPATH, and when he set LIBDIRPATH=/usr/lib,
everything worked fine.  Unfortunately he never did tell me exactly
what his original LIBDIRPATH was.

I suppose there *could* be a problem if there's an older version of
rox-clib in ~/lib or the 0launch cache, but I could be wrong about
that, not understanding the libdir script or 0launch very well at this
point.

Third Issue: AddApp - Should it go in Portage?
============

I don't really mind the idea of putting 0install and AddApp in Portage,
provided the two issues above are dealt with.  (Ie, so it doesn't
interfere with any existing packages and would preferable use globally
installed packages when available).

Any discussion or suggestions?  Or issues I haven't thought of yet?

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
rox-devel mailing list
rox-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rox-devel