Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

[Marius Mauch]

On Thu, 17 Jul 2008 07:00:32 -0500
Joe Peterson <lavajoe@g.o> 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
-- 
gentoo-dev@l.g.o mailing list