| 1 |
On Tue, 15 Jul 2008 04:14:18 +0200 |
| 2 |
Marius Mauch <genone@g.o> wrote: |
| 3 |
|
| 4 |
> As a result of Cardoes earlier mail we talked a bit about possible |
| 5 |
> solutions in #gento-portage, and I suggested to let portage |
| 6 |
> automatically inject the deps based on SRC_URI pattern matching. |
| 7 |
> A mapping of extensions and their unpack deps would be kept in the |
| 8 |
> tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' |
| 9 |
|
| 10 |
At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass |
| 11 |
to implement this feature. It doesn't modify DEPEND by itself, ebuild |
| 12 |
have to call unpack_update_depend on their own for that, as automatic |
| 13 |
updates are problematic when you have to take indirect and multiple |
| 14 |
inheritance of eclasses into account. As automatic updates aren't |
| 15 |
implemented there is also no need for a RESTRICT setting or similar, |
| 16 |
and also no requirements on the order of SRC_URI/RESTRICT/inherit. |
| 17 |
|
| 18 |
The eclass also contains it's own implementation of unpack (renamed to |
| 19 |
unpack2) and src_unpack so the logic which tools/packages are used for |
| 20 |
unpacking can be maintained in a single place instead of being |
| 21 |
splitted between the package manager and the tree. |
| 22 |
|
| 23 |
If someone wants to use it I can add it on the tree (after the normal |
| 24 |
review process and being better tested), but I'll only be doing it |
| 25 |
when there is an actual demand for it (no point in adding an eclass that |
| 26 |
nobody uses). |
| 27 |
|
| 28 |
It's still possible to come up with a package-manager-based solution in |
| 29 |
the future, but for the moment the eclass should help with the |
| 30 |
immideate problem (though the problem isn't exactly new). |
| 31 |
|
| 32 |
Marius |
| 33 |
-- |
| 34 |
gentoo-dev@l.g.o mailing list |
Archives