1 |
2014-02-05 09:08 Mike Frysinger napisał(a): |
2 |
> On Saturday, February 01, 2014 21:08:11 Arfrever Frehtes Taifersar Arahesis |
3 |
> wrote: |
4 |
> > bin/isolated-functions.sh contains at least 1 useful function, which could |
5 |
> > be exposed for external consumers (without __ prefix), but must have |
6 |
> > private name (with __ prefix) when bin/isolated-functions.sh is used in |
7 |
> > ebuild environment. |
8 |
> |
9 |
> who are these mysterious external consumers ? |
10 |
|
11 |
E.g. euse, gentoo-bashcomp and potentially other tools written in bash, which need |
12 |
some data from configuration of repositories. |
13 |
|
14 |
I would like to provide 3 functions: |
15 |
- repos_read_config() |
16 |
This function would use portageq to set PORTAGE_REPOSITORIES in environment. |
17 |
|
18 |
repos_read_config() { |
19 |
eval "$(portageq envvar -v PORTAGE_REPOSITORIES)" |
20 |
} |
21 |
|
22 |
If external consumer needs also other variables, then it can directly use: |
23 |
eval "$(portageq envvar -v PORTAGE_REPOSITORIES VAR1 VAR2 VAR3)" |
24 |
|
25 |
- repos_list() |
26 |
This function would print list of names of repositories. |
27 |
|
28 |
- repo_attr() |
29 |
This function would print value of specified attribute (${2}) for specified repository (${1}). |
30 |
This function would call __repo_attr() function currently defined in bin/isolated-functions.sh. |
31 |
|
32 |
Example code: |
33 |
. portage.bash |
34 |
repos_read_config |
35 |
for repo in $(repos_list); do |
36 |
location=$(repo_attr ${repo} location) |
37 |
… |
38 |
done |
39 |
|
40 |
Calling portageq multiple times would be too slow for some tools. |
41 |
|
42 |
gentoo-bashcomp contains a custom implementation of parser of repos.conf, which could be replaced by |
43 |
calls to functions provided by Portage: |
44 |
http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bashcomp.git;a=commitdiff;h=bf91db09a102544196b21cd792ac423262656a9a |
45 |
|
46 |
> what you propose means all funcs in there now become exported API and we now |
47 |
> have to live with that. w/out any real background, i'm very hesitant to allow |
48 |
> that. |
49 |
> |
50 |
> > Possible solutions: |
51 |
> > 1. Make /usr/lib/portage/bin/isolated-functions.sh magically define |
52 |
> > non-private variants of useful functions when run in non-ebuild |
53 |
> > environment. |
54 |
> |
55 |
> this is a no-go. we should be cutting down on internal overhead. |
56 |
> |
57 |
> > 2. Provide /usr/bin/portage.bash, which would source isolated-functions.sh |
58 |
> > (and maybe other files) and define non-private variants of useful |
59 |
> > functions. /usr/bin/portage.bash would be easier sourceable due to PATH. |
60 |
> > 3. Provide /usr/lib/portage.bash, which would source isolated-functions.sh |
61 |
> > (and maybe other files) and define non-private variants of useful |
62 |
> > functions. |
63 |
> > 4. Another location... |
64 |
> > |
65 |
> > (I would probably prefer solution #2.) |
66 |
> |
67 |
> sounds like a file that should be sourced only which imo bans it from $PATH. |
68 |
> i'm aware of the magic shell behavior where `source` searches PATH, but that's |
69 |
> not an acceptable reason imo. |
70 |
|
71 |
${EPREFIX}/usr/bin/portage.bash could be installed without +x permission. |
72 |
|
73 |
${EPREFIX}/usr/bin is probably in ${PATH} in prefix environment, so ${EPREFIX}/usr/bin/portage.bash |
74 |
might be easier to use than e.g. ${EPREFIX}/usr/lib/portage.bash. |
75 |
|
76 |
> easy to add something like `portageq helpers-dir` that'd give you a path and |
77 |
> then you use that to load the various scripts directly. |
78 |
|
79 |
It would result in calling portageq twice instead of once. |
80 |
|
81 |
-- |
82 |
Arfrever Frehtes Taifersar Arahesis |