Summary: | sys-apps/portage: Add 'force' functionality to other subcommands of ebuild | ||
---|---|---|---|
Product: | Portage Development | Reporter: | konsolebox <konsolebox> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | enhancement | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Initial implementation
Implementation of it as a feature; affects digest/manifest as well Adds --noauto option Force as feature documentation patch Noauto as option documentation patch |
Created attachment 866506 [details, diff]
Implementation of it as a feature; affects digest/manifest as well
Created attachment 866507 [details, diff]
Adds --noauto option
I implemented "Ideally I think the better implementation would be to add 'force' as a FEATURE, just like 'noauto', have '--force' work as an alternative method to assign it, and add '--noauto' that also assigns 'noauto' for <em>consistency</em>. Option-based assignment has stronger priority." with the feature affecting digest and manifest subcommands as well. Only missing is the documentation changes needed to be done in make.conf(5). Created attachment 866643 [details, diff]
Force as feature documentation patch
Created attachment 866644 [details, diff]
Noauto as option documentation patch
Easily test these updates by importing https://github.com/konsolebox/overlay/tree/c78a08360e55f199bd06a3eeb9221166593fbcc9/sys-apps/portage to your ::local and enable 'unofficial' USE. Example use case for this is https://bugs.gentoo.org/911542. I was able to rebuild and install the qbittorrent package after editing its sources to get debugging output by using the following commands: ebuild /usr/portage/net-p2p/qbittorrent/qbittorrent-4.5.4.ebuild compile --force --noauto ebuild /usr/portage/net-p2p/qbittorrent/qbittorrent-4.5.4.ebuild install qmerge Such things can't be done easily when debugging directly from raw source since you'd have to make sure configurations and destination directories are properly replicated. I think it's better to only apply 'force' against subcommands specified in the ebuild command. I'll create and test that variation. |
Created attachment 866348 [details, diff] Initial implementation Allowing commands like 'compile' to be easily re-executed without needing to remove the ".command-ed" file will allow source code to be debugged more easily. Attached patch file provides concept implementation that will allow '--force' option of ebuild to also work on other subcommands that aren't 'manifest' or 'digest' with the internal effect of ignore the dot files. Currently the implementation works by adding a 'force' argument to doebuild() and doebuild_environment() which in turn assigns PORTAGE_FORCE=1 to [my]settings. This value is then recognized by spawn() and __dyn_* shell functions. Ideally I think the better implementation would be to add 'force' as a FEATURE, just like 'noauto', have '--force' work as an alternative method to assign it, and add '--noauto' that also assigns 'noauto' for <em>consistency</em>. Option-based assignment has stronger priority. This force feature most practically is usable with noauto enabled but dev should have the option to run it without it as well. And again; for <em>consistency</em>.