On 11/22/06, Jim Ramsay <i.am@...> wrote:
> 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 :)
Hi Jim! That sounds like an excellent idea...
> 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.
> - 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.
Agreed. It currently searches XDG_CONFIG_DIRS for user overrides,
allowing the sysadmin to set defaults for all users, but once a user
creates their own config file the system one is ignored.
The point to add this is in reader.py:update_user_overrides(). We
could replace load_first_config() with load_config_paths() and make it
loop over all of them, for example.
Or, the feed can be added some other way at this point (e.g., check
for a /etc/0install/local-feed/http... symlink to a local feed rather
than having an extra XML file).
> - 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.
I'm not keen on requiring a new tarball:
- It means users having to download a new version when all that
changed is that it's marked stable.
- It's risky, in that you might accidentially upload a tarball that
was different in some other way too. The current system is good for
avoiding brown-paper-bag releases because the stable versions are
bit-for-bit identical to the tested versions ;-)
- Conceptually, stability ratings are opinions about a release.
Different people may give the same binary different ratings (in
particular, two users on the same system may give a shared binary
different ratings). The web feed is just another opinion, and can
differ from the one in the download.
A simpler way may be for the ebuild process to always set the
stability to 'stable' in local versions. In fact, this is how the
injector GUI is supplied (the copy bundled with 0launch is always
"stable", while the same copy is marked as "testing" in the web feed
for a while).
This gets the behaviour which you want (I think), especially since
there will only be one ebuild version installed at once.
If you modify the program, adding '-1' to the version number may also
help. If you don't modify it at all (you just want it shared
system-wide), you could even place it directly in the system cache
> 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.
Simple solution here: unset DISPLAY during the build and it won't do
that (although if it does try to download something and it doesn't
trust the key then it will still try to check on the console). Using
"0launch --offline" will help, provided that *some* version is
available (which it will be if the ebuild depends on it). We might
need an environment variable here (ZERO_INSTALL_OFFLINE_MODE=1 or
something) to make this easier.
The 0compile stuff may change things here anyway. I'm not keen on
downloading stuff during the compile, because it means the user has to
download packages one at a time. The preferred solution is to list all
the build dependencies in the interface and have the build process
just look at its environment variables.
> 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).
If you produce an ebuild, let me know and I'll add it to the downloads
page on 0install.net. Thanks!
Dr Thomas Leonard http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1