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