Marius Mauch wrote:
> The eclass also contains it's own implementation of unpack (renamed to
> unpack2) and src_unpack so the logic which tools/packages are used for
> unpacking can be maintained in a single place instead of being
> splitted between the package manager and the tree.
Marius, these look like nice functions. A couple of questions:
1) Since it requires altering an ebuild to use these features (i.e. no
automatic), what is the advantage over just including the dep the usual way?
2) The name "unpack2" is intended to be temporary, right? ;) I'd guess that
after this functionality is integrated into portage, there would be no need
for the extra unpack func. But then we'd probably have to keep "unpack2" for
a long time as an alias. Any way to avoid that?
3) Same would go for the needed call for unpack_update_depend, correct? I.e.
it would not be needed after portage has this functionality (and at that
point, the unpack and dep code would be unified cleanly). So this function
would then become a stub, correct? The only thing here is that ebuilds could
linger for some time without being "cleaned up".
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
