[gentoo-portage-dev] Moving ebuild-related where they belong

[Simon Stelling]

Hi all,

I have thought a bit more about how to better organize the bash-side of
portage and came to the conclusion that modularization of ebuild.sh (as
proposed in the recent thread "Refactoring ebuild.sh") can't be the only
and is not the best thing to do.

There is a fair amount of shell scripts and functions in the portage svn
repo that do not really belong there. For example all do*/new* scripts
in the bin/ directory. These are scripts that are not specific to
portage's implementation but the ebuilds that use it. That's why I think
we should move them more towards the ebuilds: Inside the tree.

This has the advantage that paludis/pkgcore don't have to keep their
helper scripts in sync with portages, that they get more visible to
ebuild devs (to some, especially the new ones, they seem like magic
commands that just come out of the middle of nowhere) and most
importantly, that they are where they belong. ;o)

Having them in the tree rather than portage would avoid bugs along the
lines of bug 121317 [1] and bug 136792 [2], or at least pull them off
portage's radar. As those functions are really the ebuild devs' area,
that's only a good thing, IMO.

As they reminded me very much of eclass functions, I converted them into
functions and put together an 'install-helpers.eclass'. Having them as
functions has the advantage of being able to create all of the new*
functions with zero redundancy and only few lines of code and being in
the same line as other helping utilities like the ones provided by
eutils and other eclasses. It has the disadvantage of not being able to
execute them with `find -exec' or `xargs'. However, that is not too much
of a problem in my eyes: I scanned the tree and out of the ~2400 ebuilds
that use find -exec/exec/xargs, none used it in combination with the
scripts I propose to convert to functions.

Having them in an eclass raises the problem of ebuilds having to inherit
said eclass, though. Even if it would be the correct way, I am not all
that keen on adding a 'inherit install-helpers' to ~15'000 ebuilds, so I
solved the problem this way:

--- ebuild.sh	2006-09-03 15:39:22 UTC
+++ ebuild.sh	2006-09-03 15:53:02 UTC
@@ -1350,6 +1350,9 @@
 # this can be left out of ebd variants, since they're unaffected.
 unset EBUILD_DEATH_HOOKS

+# let the profiles define eclasses to automatically load for every ebuild
+[[ -n ${PORTAGE_ECLASS_AUTOLOAD} ]] && inherit ${PORTAGE_ECLASS_AUTOLOAD}
+
 source ${EBUILD} || die "error sourcing ebuild"
 if ! hasq depend $EBUILD_PHASE; then
 	RESTRICT="${PORTAGE_RESTRICT}"

Setting PORTAGE_ECLASS_AUTOLOAD enables every repository to define its
own set of "standard functions".

Note that I don't really care how the functions/scripts get into the
tree, it only matters to me *that* they are in the tree, so I'm open to
other suggestions. Also, this is probably not the only heap of functions
to move out of portage into the tree, I just didn't want to do more
before I know what way to choose.

Suggestions, comments, alternative approaches, flames, all are welcome.

[1] http://bugs.gentoo.org/show_bug.cgi?id=121317
[2] http://bugs.gentoo.org/show_bug.cgi?id=136792

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer