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

[Marius Mauch]

On Sun, 20 Jul 2008 17:41:58 +0400
Peter Volkov <pva@g.o> wrote:

> В Чтв, 17/07/2008 в 04:51 +0200, Marius Mauch пишет:
> > At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass
> > to implement this feature.
>
> Marius, although it's possible to do this things in eclass why is
> eclass better? As I see portage's unpack() already has extension <->
> "program to unpack" relation. Basically unpack() in ebuild.sh has the
> following code:
>
> unpack() {
> [snip]
>         case "${x##*.}" in
>             tar)
>                 tar xof "${srcdir}${x}" ${tar_opts} || die "$myfail"
>                 ;;
>             tgz)
>                 tar xozf "${srcdir}${x}" ${tar_opts} || die "$myfail"
> [snip and so on...]
>
> This means that every ebuild which uses 'unpack ${A}' should have in
> DEPEND a program which is selected by filename extension of sources.
> So as I understood your initial suggestion was to make this happen
> automatically. And this is very logical as makes ebuilds cleaner and
> more terse. So why did you changed your mind and try to write another
> eclass (which then should sit in the tree forever), to create
> duplicate unpack function instead of just making step you suggested
> initially? Is there any intension to remove unpack logic from package
> manager? And if yes, why?

The eclass is provided as a proof-of-concept implementation that can be
used without adding additional infrastructure and implementing and
defining a new EAPI version. PM-based solutions would be nicer
long-term, but are also more tricky to "get right" (mainly a question
of where to inject the deps). Also the eclass approach has the benefit
that the whole unpack logic can be maintained in one location vs. being
split between multiple places in the package manager and the tree, and
is easier to extend (no need for an EAPI change just to add a new unpack
format). 
And as you ask, there have been plans to move quite a bit of
the bash code from portage into the tree (transparently to ebuilds
though) as that's the better place to maintain many helper functions
like do* or new* that are only used by ebuilds/eclasses and not portage.
But those plans have already existed for years (long before EAPI
existed) without anything happening, and they've never been very
specific wrt what exactly could be moved.
Even with a PM-based solution it might be useful, depending on the
actual implementation, to have the unpack() funtion in the tree, for
the reasons outlined in the first paragraph.

Marius