1 |
Michał Górny wrote: |
2 |
> Sometimes it is necessary for a single package to pull from multiple |
3 |
> remote repositories. |
4 |
<snip> |
5 |
> Another question is how to implement it API-wide. The main problem here |
6 |
> is that we already use multiple values for EGIT_REPO_URI to support |
7 |
> fallback URIs, and I'd prefer supporting that for the additional repos |
8 |
> as well. |
9 |
|
10 |
So currently: EGIT_REPO_URI="uri fallbackA fallbackB fallbackC" |
11 |
..where A, B and C are all fallbacks for uri. |
12 |
|
13 |
> EGIT_REPO_URI=( "repo1 fallback1" "repo2 fallback2" ) |
14 |
|
15 |
Would require you to support both the above, and the new syntax if it's an |
16 |
array. Since this is new functionality, it seems wiser to prevent confusion |
17 |
between: |
18 |
EGIT_REPO_URI=(uri fallbackA fallbackB fallbackC) |
19 |
and: |
20 |
EGIT_REPO_URI=(repo1 repo2 repo3 repo4) |
21 |
..and also make the implementation simpler (ie quicker for metadata), by |
22 |
using a new variable. |
23 |
|
24 |
Semantically as well, it's the git repo for the package: in most cases |
25 |
that's all that's required, so keep it simple for the majority usage (ie |
26 |
separate.) |
27 |
|
28 |
> 2/ Exherbo way would be doing something like: |
29 |
> |
30 |
EGIT_SECONDARY_REPOS='foo bar' |
31 |
EGIT_foo_REPO_URI='repo1 fallback1' |
32 |
EGIT_bar_REPO_URI='repo2 fallback2a fallback2b' |
33 |
.. |
34 |
if use baz; then |
35 |
EGIT_SECONDARY_REPOS+=' baz' |
36 |
EGIT_baz_REPO_URI='repo3 fallback3' |
37 |
fi |
38 |
|
39 |
> but that would be real PITA for smart-live-rebuild, and I really hate |
40 |
> dynamically named variables. |
41 |
> |
42 |
It's amateurishly-done as well, but there's no fixing the ugliness, nor a |
43 |
requirement for duplication, even if you fix the fail. I'd go into it, but |
44 |
technical posts I make, discussing implementation, seem to get taken as |
45 |
political, so I'll stop here, given the provenance, and stick to the RFC. |
46 |
|
47 |
> 3/ I'm wondering about something in-between those two, supposedly: |
48 |
> |
49 |
> EGIT_SECONDARY_REPO_URIS=( "repo2 fallback2" ... ) |
50 |
> |
51 |
> Still painful for s-l-r but could be implemented without |
52 |
> eclass-specific hacks as array support. Of course, if we support this |
53 |
> not only for fetching but for checkouts as well, it's likely to get |
54 |
> unreadable as well... |
55 |
> |
56 |
> What are your ideas? |
57 |
> |
58 |
Assuming an identifier/ tag as above is useful, since you can then |
59 |
clone to a named subdirectory, or fetch from a specific repo, as directed by |
60 |
the ebuild, or fetch all except the named ones, which might be fetched into |
61 |
a different base-directory when the caller has cd'ed there, etc, extend your |
62 |
last one with optional tags: |
63 |
|
64 |
EGIT_SECONDARY=("foo@ repo1 fallback1" "repo2 fallback2a fallback2b") |
65 |
.. |
66 |
use baz && EGIT_SECONDARY+=("baz@ repo3 fallback3") |
67 |
|
68 |
So, fake associative arrays in a less cluttered fashion than 2/, that are |
69 |
simple to lex in-script, and don't lead to visual or mental overload. |
70 |
|
71 |
Since tags are optional, this accepts the same format, and extends it only |
72 |
when the ebuild needs a tag, so simple builds stay simple. The @ symbol is |
73 |
not valid in url's iirc, leave alone git uris, and draws attention to the |
74 |
named items. It preserves ordering, which an associative array won't, and |
75 |
you only ever have to worry about one variable name. Nor is there any issue |
76 |
with making sure tags and variables are in sync. (DRY.) |
77 |
|
78 |
The simple tag enables all the stuff I mentioned above, and by giving the |
79 |
ebuild author a symbolic reference which can be passed around, it can be |
80 |
extended ad-hoc. |
81 |
|
82 |
-- |
83 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |