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.)
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. 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. >> 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 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 ;) Regards, Steve. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
