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 ;-)
