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