Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Steven J Long <slong@...>
Subject: Re: RFC: git-2.eclass & fetching from multiple repos
Date: Sun, 20 May 2012 12:40:35 +0100
Michał Górny wrote:
> Sometimes it is necessary for a single package to pull from multiple
> remote repositories.
> Another question is how to implement it API-wide. The main problem here
> is that we already use multiple values for EGIT_REPO_URI to support
> fallback URIs, and I'd prefer supporting that for the additional repos
> as well.

So currently: EGIT_REPO_URI="uri fallbackA fallbackB fallbackC"
..where A, B and C are all fallbacks for uri.

> EGIT_REPO_URI=( "repo1 fallback1" "repo2 fallback2" )

Would require you to support both the above, and the new syntax if it's an 
array. Since this is new functionality, it seems wiser to prevent confusion 
  EGIT_REPO_URI=(uri fallbackA fallbackB fallbackC)
  EGIT_REPO_URI=(repo1 repo2 repo3 repo4)
..and also make the implementation simpler (ie quicker for metadata), by 
using a new variable.

Semantically as well, it's the git repo for the package: in most cases 
that's all that's required, so keep it simple for the majority usage (ie 

> 2/ Exherbo way would be doing something like:
EGIT_foo_REPO_URI='repo1 fallback1'
EGIT_bar_REPO_URI='repo2 fallback2a fallback2b'
if use baz; then
   EGIT_baz_REPO_URI='repo3 fallback3'

> but that would be real PITA for smart-live-rebuild, and I really hate
> dynamically named variables.
It's amateurishly-done as well, but there's no fixing the ugliness, nor a 
requirement for duplication, even if you fix the fail. I'd go into it, but 
technical posts I make, discussing implementation, seem to get taken as 
political, so I'll stop here, given the provenance, and stick to the RFC.

> 3/ I'm wondering about something in-between those two, supposedly:
> EGIT_SECONDARY_REPO_URIS=( "repo2 fallback2" ... )
> Still painful for s-l-r but could be implemented without
> eclass-specific hacks as array support. Of course, if we support this
> not only for fetching but for checkouts as well, it's likely to get
> unreadable as well...
> What are your ideas?
Assuming an identifier/ tag as above is useful, since you can then 
clone to a named subdirectory, or fetch from a specific repo, as directed by 
the ebuild, or fetch all except the named ones, which might be fetched into 
a different base-directory when the caller has cd'ed there, etc, extend your 
last one with optional tags:

EGIT_SECONDARY=("foo@ repo1 fallback1" "repo2 fallback2a fallback2b")
use baz && EGIT_SECONDARY+=("baz@ repo3 fallback3")

So, fake associative arrays in a less cluttered fashion than 2/, that are 
simple to lex in-script, and don't lead to visual or mental overload.

Since tags are optional, this accepts the same format, and extends it only 
when the ebuild needs a tag, so simple builds stay simple. The @ symbol is 
not valid in url's iirc, leave alone git uris, and draws attention to the 
named items. It preserves ordering, which an associative array won't, and 
you only ever have to worry about one variable name. Nor is there any issue 
with making sure tags and variables are in sync. (DRY.)

The simple tag enables all the stuff I mentioned above, and by giving the 
ebuild author a symbolic reference which can be passed around, it can be 
extended ad-hoc.

#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

RFC: git-2.eclass & fetching from multiple repos
-- Michał Górny
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC: git-2.eclass & fetching from multiple repos
Next by thread:
forcing recent patch-2.6.1 everywhere
Previous by date:
Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass
Next by date:
Re: autotools.eclass:eautoreconf now runs autopoint for you

Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.