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

[Steven J Long]

Zac Medico wrote:

> 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.
>
Yeah, not something I see myself using a lot but I can see the attraction
for an end-user. (Standard technique is to only run scripts/include config
if they are marked executable.) OFC the utility is limited, as ferringb
outlined many moons ago [1], since the only variables available for an
external as opposed to source'd scriptlet are those exposed in the process
environment.
I guess that argues for just sourcing those? Dunno, some input from javaJake
would be good here, eh? ;)

[1] recommended for anyone who wants more insight into why we have bashrc
the way we do:
http://www.mail-archive.com/gentoo-portage-dev%40lists.gentoo.org/msg00544.html

>> 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. .. 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.

Is there some sort of issue with mtime checks that isn't dealt with via
git's technique of a config-flag for coarser-grained checks?
(I'm all for stricter digest based checking as well, but it seems odd we
can't use the mtime to key off, at least by default.)

> 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.
<snip>

Certainly seems to be room to play with cache generation, or better to allow
overlay to distribute a per-repo cache. That could be rsync'ed alongside
the standard vcs-managed files, to avoid the hit of storing it in the vcs.
Might be worth considering a git digest as one of the types?

>> 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.
>
That sounds nice; we have clear exemplars of use-case for each one. We're
really looking at two types: metadata-only and user (use latest version
whenever we're called, and don't save in binpkg) with policy enforced for
tree or overlay.

>>>> 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.

Er yeah, sorry was tired and tidying up before holiday.

> 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).
>
Yeah binary packages were the other concern.
 
>> 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.
>
Hmm is this where we get into eclass digests? (again;)

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)