Summary: | emerge should make autounmask-written file name configurable | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Denis Lisov <dennis.lissov> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | esigra |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 376695 |
Description
Denis Lisov
2013-04-07 06:08:32 UTC
This feels like feature bloat to me, since you can edit the files yourself if you feel the need to organize them. (In reply to comment #0) > If the settings in the named file are known to be overridden later, an error > should be produced. Doing a check for overrides is going to involve creating of dummy configurations and testing them to see how they interact with the relevant packages. It's certainly doable, but it's not a small amount of work. (In reply to comment #1) > This feels like feature bloat to me, since you can edit the files yourself > if you feel the need to organize them. Well, why do we have --autounmask-write, then? You can copy the lines printed by --autounmask to the config files by hand. > (In reply to comment #0) > > If the settings in the named file are known to be overridden later, an error > > should be produced. > > Doing a check for overrides is going to involve creating of dummy > configurations and testing them to see how they interact with the relevant > packages. It's certainly doable, but it's not a small amount of work. I do not mean complete coverage with dummy configurations. It may just remember which file was the setting taken from and check for every new setting proposed whether the source file of the original setting would be sourced later than the file to be written. (In reply to comment #2) > (In reply to comment #1) > > This feels like feature bloat to me, since you can edit the files yourself > > if you feel the need to organize them. > > Well, why do we have --autounmask-write, then? You can copy the lines > printed by --autounmask to the config files by hand. Well, I think it's obvious that --autounmask-write is useful to everyone. On the otherhand, making the file names configurable would only useful to people who make use of split configuration files, and who also don't keep all of the autounmask changes in a file named 99-autounmask or similar. |