1 |
On 22.03.2018 01:25, Zac Medico wrote: |
2 |
> On 03/19/2018 09:49 PM, Manuel Rüger wrote: |
3 |
>> Hi Zac, |
4 |
>> |
5 |
>> alternatively could --exclude be extended to support sets? |
6 |
>> So users could --exclude @world or @profile. |
7 |
> |
8 |
> Your idea doesn't really fit the current meaning of --exclude, since |
9 |
> --exclude excludes packages from being merged, but still adds installed |
10 |
> instances to the dependency graph in order to ensure that their |
11 |
> dependencies remain satisfied. |
12 |
> |
13 |
Thanks for providing the clarification, now I have a better |
14 |
understanding what both approaches do and withdraw my suggestion for |
15 |
this patch. :-) |
16 |
|
17 |
> I'd question the usefulness of a finer-grained approach that you're |
18 |
> suggesting. I don't foresee people wanting to fiddle around with which |
19 |
> package sets they want to ignore, and I wouldn't encourage them to do so. |
20 |
> |
21 |
> The intention of the --ignore-world option is to say, "I only care about |
22 |
> the packages that I'm specifying in the emerge arguments, do anything |
23 |
> necessary to install them." In this sort of situation, I think a person |
24 |
> generally wants to ignore everything except the given packages and their |
25 |
> dependencies, because they don't want to do a bunch of fiddling to |
26 |
> figure out which sets they'd need to exclude in order to avoid |
27 |
> conflicts. If they want to fiddle with something, they are free to |
28 |
> adjust their package set configuration, so why wouldn't they? |
29 |
> |
30 |
> Anyway, I'm not necessarily opposed to adding a finer grained |
31 |
> --ignore-set option. However, it would be more work, it would be more |
32 |
> complex, and I wouldn't advise anyone to use it. |
33 |
> |
34 |
> If people want to automate something in a disposable system, or they're |
35 |
> in a position to use --ask and check the result for sanity, then I think |
36 |
> --ignore-world is a good solution. |
37 |
> |
38 |
> If people want something that's safe to use on a production system, then |
39 |
> I'll advise them to manually adjust their package set configuration. |
40 |
> |