1 |
Steven J Long wrote: |
2 |
> Zac Medico wrote: |
3 |
> |
4 |
>> Steven J Long wrote: |
5 |
>>> Yeah sounds right. Perhaps a per-category bashrc split (both for |
6 |
>>> usual /etc/portage case and for overlays) might also be useful? |
7 |
>>> (Overlay admin can always test PN should the need arise.) |
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 |
That seems like a reasonable use-case for per-phase sourcing. |
20 |
|
21 |
> For an overlay, from what I've seen in my limited exposure to the issue, |
22 |
> there is more of a need for influencing metadata, eg IUSE. I hesitate to |
23 |
> speak for the sunrise bods, and any other overlay admins, on this, though, |
24 |
> so if you're reading this, guys, please chip in. :) That ties in more with |
25 |
> the next point; although as you say it could be done by inheritance from an |
26 |
> eclass, again that potentially involves editing the ebuild. |
27 |
|
28 |
Note that any changes to ebuild metadata generation mean changes in |
29 |
metadata cache validation. For example, if you want to modify ebuild |
30 |
metadata from profile.bashrc, then you have to make sure to |
31 |
invalidate metadata cache any time the profile.bashrc is modified. |
32 |
If such a change affects all ebuilds in the repo, it can be time |
33 |
consuming to regenerate all of the metadata cache. Also, if the |
34 |
cache validation mechanism isn't robust enough, users will |
35 |
experience annoying issues with stale cache. For example see this bug: |
36 |
|
37 |
http://bugs.gentoo.org/show_bug.cgi?id=139134 |
38 |
|
39 |
Also, see this related discussion on cache validation: |
40 |
|
41 |
|
42 |
http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml |
43 |
|
44 |
> With the existing bashrc capability end-users can do all this ourselves; |
45 |
> it'd just be nice to be able to do it in overlays, and for what we already |
46 |
> have to be specified since it applies to both pkgcore and portage, and has |
47 |
> done for several years. |
48 |
|
49 |
We might want to have two separate bashrcs. One that's per-phase, |
50 |
and another one that's only sourced once. If it's only sourced once |
51 |
then it might allow you to make more radical changes that you |
52 |
couldn't otherwise make without breaking uninstall phases in some way. |
53 |
|
54 |
>>> You mentioned in #-portage that per-phase execution is no longer used, |
55 |
>>> wrt how overlays would only be executing bashrc at start. I take it we |
56 |
>>> can still test $EBUILD_PHASE? (Sorry if I've misunderstood what you were |
57 |
>>> saying.) |
58 |
>> Current portage bashrc support allows $EBUILD_PHASE conditionals, |
59 |
>> but I think in the long term we may want to drop that in favor of |
60 |
>> function hooks that are sourced only once. The $EBUILD_PHASE |
61 |
>> conditional approach just seems somewhat clumsy in comparison |
62 |
>> (sourcing the bashrc during every phase might also be considered |
63 |
>> inefficient/ugly). |
64 |
> |
65 |
> My only concern here is that changes the admin makes, eg in |
66 |
> post_pkg_postinst, won't be reflected in uninstalling a package which was |
67 |
|
68 |
I assume you mean post_pkg_postrm, since post_pkg_postinst is never |
69 |
executed during uninstall. Well, it is for the replacing package, if |
70 |
there is one, but that should have the latest environment anyway (at |
71 |
least, assuming it's not a binary package). |
72 |
|
73 |
> installed before the change. For the DEPEND phase, as in IUSE modification, |
74 |
> that's not so much a problem afaict, since a) it's not typically what |
75 |
> network admins want to tweak, and b) it's right at the start of the whole |
76 |
> process. Any clarity you want to add will be gratefully received ;) |
77 |
|
78 |
Again, metadata changes introduce cache validation issues that need |
79 |
to be carefully considered. |
80 |
|
81 |
> Regards, |
82 |
> Steve. |
83 |
|
84 |
|
85 |
-- |
86 |
Thanks, |
87 |
Zac |