Re: [gentoo-dev] Re: Re: Re: stacking profile.bashrc?

[Zac Medico <zmedico@gentoo.org>]

Steven J Long wrote:
> Zac Medico wrote:
> 
>> Steven J Long wrote:
>>> Yeah sounds right. Perhaps a per-category bashrc split (both for
>>> usual /etc/portage case and for overlays) might also be useful?
>>> (Overlay admin can always test PN should the need arise.)
>> Maybe that's more in the domain of eclasses (or some sort of elibs
>> is they don't need to change metadata), in cases when it's easy
>> enough to inherit whichever ones are needed.
>>
> Well the directory-based approach is for network/overlay admins or
> downstream distros to tweak stuff without needing to edit and digest
> ebuilds in a local overlay. JavaJake wanted to split the actual phases, so
> we have a directory per-phase, which can ofc easily be done with a bit of
> BASH or shell-script from the existing bashrc. This seems more useful for
> end-user admins (whether local or network.)

That seems like a reasonable use-case for per-phase sourcing.

> For an overlay, from what I've seen in my limited exposure to the issue,
> there is more of a need for influencing metadata, eg IUSE. I hesitate to
> speak for the sunrise bods, and any other overlay admins, on this, though,
> so if you're reading this, guys, please chip in. :) That ties in more with
> the next point; although as you say it could be done by inheritance from an
> eclass, again that potentially involves editing the ebuild.

Note that any changes to ebuild metadata generation mean changes in
metadata cache validation. For example, if you want to modify ebuild
metadata from profile.bashrc, then you have to make sure to
invalidate metadata cache any time the profile.bashrc is modified.
If such a change affects all ebuilds in the repo, it can be time
consuming to regenerate all of the metadata cache. Also, if the
cache validation mechanism isn't robust enough, users will
experience annoying issues with stale cache. For example see this bug:

  http://bugs.gentoo.org/show_bug.cgi?id=139134

Also, see this related discussion on cache validation:


http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml

> With the existing bashrc capability end-users can do all this ourselves;
> it'd just be nice to be able to do it in overlays, and for what we already
> have to be specified since it applies to both pkgcore and portage, and has
> done for several years.

We might want to have two separate bashrcs. One that's per-phase,
and another one that's only sourced once. If it's only sourced once
then it might allow you to make more radical changes that you
couldn't otherwise make without breaking uninstall phases in some way.

>>> You mentioned in #-portage that per-phase execution is no longer used,
>>> wrt how overlays would only be executing bashrc at start. I take it we
>>> can still test $EBUILD_PHASE? (Sorry if I've misunderstood what you were
>>> saying.)
>> Current portage bashrc support allows $EBUILD_PHASE conditionals,
>> but I think in the long term we may want to drop that in favor of
>> function hooks that are sourced only once. The $EBUILD_PHASE
>> conditional approach just seems somewhat clumsy in comparison
>> (sourcing the bashrc during every phase might also be considered
>> inefficient/ugly).
> 
> My only concern here is that changes the admin makes, eg in
> post_pkg_postinst, won't be reflected in uninstalling a package which was

I assume you mean post_pkg_postrm, since post_pkg_postinst is never
executed during uninstall. Well, it is for the replacing package, if
there is one, but that should have the latest environment anyway (at
least, assuming it's not a binary package).

> installed before the change. For the DEPEND phase, as in IUSE modification,
> that's not so much a problem afaict, since a) it's not typically what
> network admins want to tweak, and b) it's right at the start of the whole
> process. Any clarity you want to add will be gratefully received ;)

Again, metadata changes introduce cache validation issues that need
to be carefully considered.

> Regards,
> Steve.


-- 
Thanks,
Zac