On Thu, 17 Jul 2008 07:00:32 -0500 Joe Peterson <[EMAIL PROTECTED]> wrote:
> 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? You wouldn't have to maintain the relevant deps, e.g. when you change SRC_URI, when the unpack implementation changes (e.g. adding support for new unpackers) or keeping the conditionals in sync with SRC_URI. > 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? Well, it can't be named unpack to avoid conflicts with the internal portage function. If this functionality would be added on the PM side then there would be no more need for the eclass (you wouldn't want to use both implementations at the same time), and it would be opt-in via a new EAPI, so you'd have to change the ebuilds anyway to benefit from it. So I don't see a need to have a unpack2 alias outside the eclass. > 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". See above. Marius -- [email protected] mailing list
