| 1 |
>>>>> On Sat, 13 Aug 2011, Ciaran McCreesh wrote: |
| 2 |
|
| 3 |
>> Except that large parts of the tree rely on packages in RDEPEND |
| 4 |
>> being available in pkg_*. |
| 5 |
|
| 6 |
> Then those packages are broken. |
| 7 |
|
| 8 |
Welcome to reality. ;-) |
| 9 |
|
| 10 |
>> > If there's a need for dependencies that will definitely be |
| 11 |
>> > installed for pkg_setup, we should introduce an IDEPEND (for |
| 12 |
>> > 'install'). |
| 13 |
>> |
| 14 |
>> And then at some point we will have circular IDEPEND dependencies |
| 15 |
>> and the package manager will have to break such cycles, as it does |
| 16 |
>> for RDEPEND now. |
| 17 |
|
| 18 |
> No, IDEPEND will simply not allow cycle breaking, in the same way as |
| 19 |
> DEPEND. IDEPEND would be, in effect, DEPEND that is also honoured |
| 20 |
> for binary packages. |
| 21 |
|
| 22 |
I'm not convinced. IDEPEND would cover a very specific usage case, and |
| 23 |
IMHO it wouldn't be so different from an intersection of DEPEND and |
| 24 |
RDEPEND. Not different enough to justify introduction of another |
| 25 |
variable. |
| 26 |
|
| 27 |
Maybe package managers could introduce it as an internal variable |
| 28 |
(containing packages common to DEPEND and RDEPEND)? And in case that |
| 29 |
we should at some point switch to an Exherbo-style syntax for |
| 30 |
dependencies, then it could be specified explicitly? |
| 31 |
|
| 32 |
Ulrich |
Archives