| 1 |
Ciaran McCreesh wrote: |
| 2 |
> On Tue, 15 Jul 2008 12:23:08 -0700 |
| 3 |
> Donnie Berkholz <dberkholz@g.o> wrote: |
| 4 |
>> Could someone explain why manually doing work is better than |
| 5 |
>> automatically detecting the deps? This sounds like an argument |
| 6 |
>> against automation, and I'm not following it. |
| 7 |
> |
| 8 |
> Sometimes the magic will be wrong. For example, packages that have |
| 9 |
> a .zip file in SRC_URI but that don't unpack that file (say, if they |
| 10 |
> install it into sharedir as-is instead) don't need a dep upon unzip. |
| 11 |
> |
| 12 |
|
| 13 |
Couldn't the ebuild be wrong? For example, if the package manager uses |
| 14 |
fancy-unzip-replacement to unzip packages, but the ebuild depends on |
| 15 |
unzip, then wouldn't it fail? It seems like we're trying to have |
| 16 |
ebuilds DEPEND on something that in reality the package manager is doing. |
| 17 |
|
| 18 |
Shouldn't the package manager depend on unzip instead? If circular |
| 19 |
references are the problem, then wouldn't it be better to find a better |
| 20 |
way to handle circular references (ie more specific ways of defining |
| 21 |
dependencies)? |
| 22 |
|
| 23 |
The advantage I see with automagic PM dependency calculations is that |
| 24 |
the PM is the program calling unzip, so the PM ought to be able to |
| 25 |
figure out whether it needs to call unzip. |
Archives