Description of problem: Currently if write plugin, which is intended only for root, I have to put somewhere logic of: if uid != 0: print "you are not root user, go away" sys.exit It would be nice to have class boolean attribute root_only, which would indicate if you must be root to call it. And this check would be done by DNF itself and DNF would print unified error message and unified exit code.
We discussed this at the DevConf. Waiting for the moment to do the proper signup mechanism support, where root-user will be one of the elements commands can signup for.
As I continued with coding of plugin I do not longer think it should be attribute of class. Because I want to create plugin which use command alias "copr" and it will have subcommands "enable" which will be for root only. And subcommand "search", which will be available for everybody. So I would rather see dnf.cli.Command.check_for_root(), which I would call in moments when some action require to be run by root.
Just sent patch. https://github.com/akozumpl/dnf/pull/89
for copr I've implemented in test mode (in separate branch) https://git.fedorahosted.org/cgit/copr.git/commit/?h=check-root It works with patched dnf.
However such a method does not allow DNF (e.g. noroot plugin) to check whether a command requires root privileges. The simplest solution would be to add a method which accepts CLI arguments and returns the information whether the command needs such privileges. I would prefer a new method 'configure' which accepts CLI arguments and configures all those "properties". Currently, the sub-commands problem is worked around by defining the 'writes_rpmdb' as a property and setting its value during 'run'. See similar thing here: https://github.com/akozumpl/dnf/blob/master/dnf/cli/commands.py#L743
I really dislike adding a special method for this until we know figure out there's nothing better we can do. Let's leave this sitting for now.
Provided by aee2170 on master. The commands can now do: cli.demands.root_user = True This and other demands should can take place in their configure() method as Radek writes comment 5.
dnf-0.5.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnf-0.5.1-1.fc20
Package dnf-0.5.1-1.fc20, hawkey-0.4.14-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-0.5.1-1.fc20 hawkey-0.4.14-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5937/hawkey-0.4.14-1.fc20,dnf-0.5.1-1.fc20 then log in and leave karma (feedback).
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20
Package dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.0.8-2.fc20 libsolv-0.6.1-1.git6d968f1.fc20 hawkey-0.4.16-1.fc20 dnf-0.5.2-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6789/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20 then log in and leave karma (feedback).
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.