| 1 |
On 03/21/2018 05:59 PM, Manuel Rüger wrote: |
| 2 |
> On 22.03.2018 01:25, Zac Medico wrote: |
| 3 |
>> On 03/19/2018 09:49 PM, Manuel Rüger wrote: |
| 4 |
>>> Hi Zac, |
| 5 |
>>> |
| 6 |
>>> alternatively could --exclude be extended to support sets? |
| 7 |
>>> So users could --exclude @world or @profile. |
| 8 |
>> |
| 9 |
>> Your idea doesn't really fit the current meaning of --exclude, since |
| 10 |
>> --exclude excludes packages from being merged, but still adds installed |
| 11 |
>> instances to the dependency graph in order to ensure that their |
| 12 |
>> dependencies remain satisfied. |
| 13 |
>> |
| 14 |
> Thanks for providing the clarification, now I have a better |
| 15 |
> understanding what both approaches do and withdraw my suggestion for |
| 16 |
> this patch. :-) |
| 17 |
|
| 18 |
Ok, glad to clarify. Thinking some more on the implications of your |
| 19 |
question, it seems like you were thinking that packages matched by the |
| 20 |
excluded set would somehow be magically eliminated from the dependency |
| 21 |
graph? That's not how --ignore-world works at all. Things matched by |
| 22 |
@world, @selected, @system, and their deep dependencies can still be |
| 23 |
pulled into the dependency graph despite --ignore-world. The only |
| 24 |
difference with --ignore-world is that @world is no longer an implicit |
| 25 |
member of the dependency graph, so --complete-graph options will not |
| 26 |
force @world into the dependency graph, and the packages given as |
| 27 |
arguments will be the only root(s) of the dependency graph. |
| 28 |
-- |
| 29 |
Thanks, |
| 30 |
Zac |
Archives