1 |
On Sat, 21 Nov 2015 18:49:03 -0500 |
2 |
Ian Stakenvicius <axs@g.o> wrote: |
3 |
|
4 |
> -----BEGIN PGP SIGNED MESSAGE----- |
5 |
> Hash: SHA256 |
6 |
> |
7 |
> On 21/11/15 06:29 PM, NP-Hardass wrote: |
8 |
> > Probably not the ideal solution given that you seem to prefer |
9 |
> > removal of such variables, but a REPODIR variable which is set to |
10 |
> > the directory where the repo is (basically making PORTDIR dynamic |
11 |
> > and setting it on a per package basis) could enable developers |
12 |
> > to reference their repo when needed, allowing variable use in a |
13 |
> > multi repo system. Additionally, if that idea is liked, I think |
14 |
> > an array of the repos masters and/or their dirs (or some |
15 |
> > functions to access that information) could also be useful. Like |
16 |
> > get_masters and get_repo_dir functions. |
17 |
> > |
18 |
> |
19 |
> - From your description here REPODIR would only point to the current |
20 |
> repo, so for licence-file access when the license is in the main |
21 |
> gentoo repo, but the current repo is an overlay, it would still fail. |
22 |
> |
23 |
> Similar cases could occur for eclasses, especially since 'masters' |
24 |
> in repo metadata allows multiple repos to be chained. |
25 |
|
26 |
There's also the eclass-overrides problem. |
27 |
|
28 |
> All told, I think i'm in favour of banning the variables, and |
29 |
> potentially providing getter functions that would output the path of |
30 |
> these files if they need to be accessed -- '$(get_eclasspath |
31 |
> [name])' or $(get_licensepath [name]) or the like. I don't know if |
32 |
> these could be implemented in-eclass or if they would be something |
33 |
> that would have to be added to EAPI7..? |
34 |
|
35 |
get_eclasspath doesn't solve the issue of storing random stuff under |
36 |
eclass/ subdirectories, I think. And if I understand your idea |
37 |
correctly, get_licensepath would still not work for binary packages. |
38 |
|
39 |
-- |
40 |
Best regards, |
41 |
Michał Górny |
42 |
<http://dev.gentoo.org/~mgorny/> |