| 1 |
On Tue, 15 Jul 2008 16:45:38 -0400 |
| 2 |
Richard Freeman <rich@××××××××××××××.net> wrote: |
| 3 |
> Couldn't the ebuild be wrong? For example, if the package manager |
| 4 |
> uses fancy-unzip-replacement to unzip packages, but the ebuild |
| 5 |
> depends on unzip, then wouldn't it fail? It seems like we're trying |
| 6 |
> to have ebuilds DEPEND on something that in reality the package |
| 7 |
> manager is doing. |
| 8 |
|
| 9 |
For current EAPIs, we pretty much mandate that 'unzipping .zip files is |
| 10 |
done using app-arch/unzip'. It's not ideal. |
| 11 |
|
| 12 |
For future EAPIs, we can have the package manager define |
| 13 |
super-magic/thing-i-use-to-unzip. |
| 14 |
|
| 15 |
> Shouldn't the package manager depend on unzip instead? If circular |
| 16 |
> references are the problem, then wouldn't it be better to find a |
| 17 |
> better way to handle circular references (ie more specific ways of |
| 18 |
> defining dependencies)? |
| 19 |
|
| 20 |
Having the package manager depend upon things like 7z for the two |
| 21 |
packages in the tree that use it isn't sane. |
| 22 |
|
| 23 |
One could argue that having package manager support for extracting 7z |
| 24 |
is also not sane, of course, but that's something we're stuck with in |
| 25 |
current EAPIs. |
| 26 |
|
| 27 |
-- |
| 28 |
Ciaran McCreesh |
Archives