- New custom boolean variable ebuild-run-as-portage-or-root (nil by default) - When ebuild-run-as-portage-or-root is non-nil, adjust user of `ebuild-run-command': run by root: install, merge, postinst, unmerge, postrm, qmerge run by default user: manifest, digest, help run by portage: (everything ese) (operations on each line are listed as in code where they are listed in subjectively determined order of frequency: the more frequent closer to the beginning) - New boolean-variable: ebuild-run-tramp-method to optionally use doas rather than sudo. This works starting from Emacs 24. I think it is reasonable enough behaviour to be default once Emacs 23 support is dropped. As implemented, the feature is not supported in XEmacs. When I tried to wrap the relevant code in mere (unless (featurep 'xemacs) ..), build failed. Apparently, whatever compiler optimizations you mentioned in our ebuild-run-mode discussion are not enough, at least in the presence of undefined setf places. Thus, the code is guarded in XEmacs with a macro (only defined at compile time). It helps with some other bulid-time issues as well. Customization variables are not present in the final XEmacs and GNU Emacs 23 builds so they won't confuse XEmacs users, and ebuild-run-command works in XEmacs and GNU Emacs 23 the way it used to. I must note, I barely understand the point of ebuild-run-command in XEmacs in the first place. I installed app-xemacs/tramp, but no matter how I tried to use it, it just fails with (process-error "Searching for program" "ftp"). Non-trivial ebuild commands will only work there if Emacs is run as root or portage. app-(x)emacs/ebuild-mode both build without warnings. I tested the new functionality with the following test-ebuild-run-as-portage-or-root.el (unless (featurep 'xemacs) (add-to-list 'load-path "/usr/share/emacs/site-lisp/ebuild-mode")) (require 'ebuild-mode) (setq ebuild-run-as-portage-or-root t) (with-current-buffer (find-file-noselect "/var/db/repos/gentoo/app-emacs/ebuild-mode/ebuild-mode-1.53.ebuild") (ebuild-run-command (if (or (featurep 'xemacs) (= 23 emacs-major-version)) "help" "clean"))) Test passes in Emacs 23--28 and in XEmacs. Test is run with emacs -Q -l ./test-ebuild-run-as-portage-or-root.el and xemacs -q -l ./test-ebuild-run-as-portage-or-root.el “Test passes” means, no errors are signalled, and “clean” command succeeds if password is entered. I don't use doas but I repeated the test with (setq ebuild-run-tramp-method "doas") in Emacs 26--28, successfully. Reproducible: Always
Created attachment 743040 [details, diff] Optionally enable reasonable defaults for running ebuild command
Correction: I suggest to run as root merge, install, postinst, preinst, unmerge, postrm, prerm, config, package, qmerge Patch reflects that; only my original post here does not.
Maybe “clean” better be run as root too. A frequent use case is visiting ebuild after a failed emerge which is run as root so clean can only be completed as root as well iirc. Also, I should remove eval from the definition of emacs-ecase.
ebuild-mode was intended as a tool for editing and testing ebuilds (i.e. operations that a developer would do before committing), but never as full package manager replacement. I have to think about the concept and the goals of the package, before I'll add root/tramp functionality.
It has nothing to do with making ebuild-mode a package manager replacement. “ebuild” commands don't do dependency resolution, and for that reason alone they can't be used for package management. I generally don't try to add something to a package if it looks out of scope enough for my efforts to be wasted. I submitted this patch because it is relevant as long as ebuild-run-command merely exists in ebuild-mode! If users are not intended to use ebuild-run-command, it makes sense to just drop it completely. Most of commands invoked with ebuild-run-command are simply useless when not running as portage or root. They will just fail, plain and simple. Meanwhile, nobody logs in as portage (is it even possible?) and it's very often undesireable to run Emacs as root. If users of ebuild-mode are not intended to run the swath of commands that require root privileges no succeed, why are those commands listed in ebuild-commands-list then? I won't suggest removing them of course because they are as useful for testing ebuilds as any other command. My rationale for this patch is, to get /anything at all/ out of ebuild-run-command besides ebuild manifest and ebuild help, currently you have to run ebuild-run-rommand as portage or root. I used to visit ebuild files as portage when my local repository was owned by portage; it was extremely inconvenient for repositories where files are not owned by portage, e.g. in repositories under version control which I maintain or to which I contribute so now my regular user owns them and visits those files. Last but not least, a repository might be on a remote machine, and there's no reason for ebuild-run-command to be non-functioning then. But you most certainly won't log in as portage or root to a remote host! This patch covers this as well, at least to some extent (I'm not sure if, in the presence of hops, it requires to adjust tramp user or rather tramp hop but this can be fixed easily for sure). I wonder how you use ebuild-mode at all. Running ebuild-run-command is by far the most frequent command I explicitly call, besides editing commands. And it's terribly inconvenient unless portage owns the ebuilds and that's how you visit them.
Correct, the portage user isn't intended to be used for interactive login, and I don't think that anyone does "sudo -u portage". When doing ebuild development work, I think the most frequent workflow includes: - add yourself to the portage group - add fakeroot to FEATURES With that, everything that is required for testing an ebuild just works, either in the terminal or in ebuild mode. As I said before, I will think about tramp integration (but only for root, not for the portage user). Also, the present code is hard to read because of the many version conditionals.
My last argument is, the suggested approach is more straightforward, not requiring additional setup external to Emacs, and working as close to the “production” environment as possible — including the ability to straightforwardly merge as soon as the issue at hand is fixed. And I just don't see any costs imposed by it, or by using sudo portage in particular. > Also, the present code is hard to read because of the many version conditionals. As long as we support a wide range of Emacs versions, the only alternative would be to use low-level string manipulations which will be yet harder to read, and error-prone; using native tramp interface is far more reliable. I think these emacs-ecase forms are as readable as it gets. Their consistent usage also allows to easily grep for version-depenedent stuff.
Regarding ebuild-run-as-portage-or-root: If I run an ebuild as root, I can not even browse the work directory. Therefore working on the code of a package as root is necessary, which is extremely tedious. So I usually run ebuilds as user, and only run them as root when merging onto the system. Please don't add install to that. Secondly I have to support you here. Maybe I set up my things wrong, but live ebuilds can only be run as root. (At least for me) Even the fetch phase. I can not run live ebuilds with ebuild-mode right now, it says (git fetch https://gitlab.gnome.org/World/planner.git +HEAD:refs/git-r3/HEAD error: cannot open '/var/cache/distfiles/git3-src/World_planner.git/FETCH_HEAD': Permission denied but your patch would also not solve that. Could we have something like a parallel ebuild-run-command called ebuild-run-command-root or somthing, that is exactly like ebuild-run-command exept that is running the commands as root?
