1 |
Zac Medico wrote: |
2 |
|
3 |
> Steven J Long wrote: |
4 |
>> Yeah sounds right. Perhaps a per-category bashrc split (both for |
5 |
>> usual /etc/portage case and for overlays) might also be useful? |
6 |
>> (Overlay admin can always test PN should the need arise.) |
7 |
> |
8 |
> Maybe that's more in the domain of eclasses (or some sort of elibs |
9 |
> is they don't need to change metadata), in cases when it's easy |
10 |
> enough to inherit whichever ones are needed. |
11 |
> |
12 |
Well the directory-based approach is for network/overlay admins or |
13 |
downstream distros to tweak stuff without needing to edit and digest |
14 |
ebuilds in a local overlay. JavaJake wanted to split the actual phases, so |
15 |
we have a directory per-phase, which can ofc easily be done with a bit of |
16 |
BASH or shell-script from the existing bashrc. This seems more useful for |
17 |
end-user admins (whether local or network.) |
18 |
|
19 |
For an overlay, from what I've seen in my limited exposure to the issue, |
20 |
there is more of a need for influencing metadata, eg IUSE. I hesitate to |
21 |
speak for the sunrise bods, and any other overlay admins, on this, though, |
22 |
so if you're reading this, guys, please chip in. :) That ties in more with |
23 |
the next point; although as you say it could be done by inheritance from an |
24 |
eclass, again that potentially involves editing the ebuild. |
25 |
|
26 |
With the existing bashrc capability end-users can do all this ourselves; |
27 |
it'd just be nice to be able to do it in overlays, and for what we already |
28 |
have to be specified since it applies to both pkgcore and portage, and has |
29 |
done for several years. |
30 |
|
31 |
>> You mentioned in #-portage that per-phase execution is no longer used, |
32 |
>> wrt how overlays would only be executing bashrc at start. I take it we |
33 |
>> can still test $EBUILD_PHASE? (Sorry if I've misunderstood what you were |
34 |
>> saying.) |
35 |
> |
36 |
> Current portage bashrc support allows $EBUILD_PHASE conditionals, |
37 |
> but I think in the long term we may want to drop that in favor of |
38 |
> function hooks that are sourced only once. The $EBUILD_PHASE |
39 |
> conditional approach just seems somewhat clumsy in comparison |
40 |
> (sourcing the bashrc during every phase might also be considered |
41 |
> inefficient/ugly). |
42 |
|
43 |
My only concern here is that changes the admin makes, eg in |
44 |
post_pkg_postinst, won't be reflected in uninstalling a package which was |
45 |
installed before the change. For the DEPEND phase, as in IUSE modification, |
46 |
that's not so much a problem afaict, since a) it's not typically what |
47 |
network admins want to tweak, and b) it's right at the start of the whole |
48 |
process. Any clarity you want to add will be gratefully received ;) |
49 |
|
50 |
Regards, |
51 |
Steve. |
52 |
-- |
53 |
#friendly-coders -- We're friendly but we're not /that/ friendly ;-) |