Allow source-install to run as non-root user

[janlinde]

zypper si refuses to run as as non-root user: "Root privileges are required to run this command."

I don't see a reason for this requirement. In fact it kills my most obvious use case: Run rpmbuild as non-root user after source-installing the package with zypper and editing the sources as needed.

This used to be si's default behaviour from the start until the restriction was introduced with commit 7827e38 into Zypper.cc, and has then propagated with commit e40bdd8 into sourceinstall.cc. The first commit mentions bsc#1066215 as its reason, but that looks unrelated.

This PR reinstantiates the original behaviour and works fine for me.

[bzeller]

As you see in the removed code in the PR you linked:
e40bdd8#diff-9fbd4b0944384bf07b515d59b4028f88L3487

zypper si did require root privs before

[janlinde]

zypper si did require root privs before

No. It required root privileges before commit e40bdd8, correct, but I wrote that it did not before commit 7827e38. This matches my experience: Running zypper si as non-root user worked for me since zypper was introduced into openSUSE, until it stopped working somewhere two years ago. You authored both commits. What motivated introducing that restriction in commit e40bdd8 in the first place? Looking at bsc#1066215 as referred to in the commit message doesn't explain that to me.

[mlandres]

It depends on the options. If the command does --no-build-deps it might work as user, provided rpms %{_specdir} and %{_sourcedir} also point to a user writable location. If build dependencies are to be installed too (which is the default) you usually need to be root.

The situation might be different if you are using a chroot environment, where you can write and install packages as non-root user. AFAIR zypper --root DIR si ... does not require root privileges in advance. It will nevertheless fail if you don't have enough privileges to complete the action.

[janlinde]

provided rpms %{_specdir} and %{_sourcedir} also point to a user writable location.

Yes, of course, that's the default:

> rpmbuild --eval '%{_specdir} %{_sourcedir}'
/home/jan/rpmbuild/SPECS /home/jan/rpmbuild/SOURCES

If build dependencies are to be installed too (which is the default) you usually need to be root.

Well, not if they are already installed. That's what zypper si -d is for, I would presume. You have to run that before if need be to prepare your build environment. Which is an installation step affecting the entire system, and as such it's perfectly fine for it to require root privileges. What's not fine is to be forced to run the compilation with superuser privileges below /usr/src/packages. That's cumbersome, not intended by RPM AFAIK, and outright insecure.

The situation might be different if you are using a chroot environment, where you can write and install packages as non-root user.

Working in a chroot alone would not save you. You'd have to run under fakeroot / pseudo.

Now, that said, what would be a real luxury solution is to have zypper si authenticate and aquire root privileges for installing the dependencies, and then proceed to install the source package as regular user. I recognize, though, that implementing privilege escalation in zypper would raise a lot more questions about usage semantics. As opposed to the the si -d / si workflow, which I do consider a straightforward no-brainer.

[mlandres]

I must admit that I usually use build or osc to build my packages in a chroot sandbox. This way the build result never depends on the content of my local system. That's probably why I never ran into this. Anyway, we can drop the need for root if --no-build-deps is used.

As a workaround in the meantime zypper download srcpackage:FOO works as user. Then you can install the downloaded .src.rpm from your local cache with rpm -i.

[janlinde]

That's probably why I never ran into this.

Yep, I figured. We run our own build automation on top of plain rpmbuild which even predates the openSUSE build service, and that's where this came up. I just thought I'd try to get the patch merged upstream.

Anyway, we can drop the need for root if --no-build-deps is used.

That would be nice, thanks! I forgot to mention: --no-build-deps is not even necessary. The patched zypper will work just fine without if you do sudo zypper si -d <pkg> && zypper si <pkg>. But I see that requiring --no-build-deps will make the error message more explicit if the -d step is omitted. A matter of taste, I suppose. Same for zypper verify.

As a workaround in the meantime zypper download srcpackage:FOO works as user.

Good idea, thank you.

[janlinde]

Anyway, we can drop the need for root if --no-build-deps is used.

I have implemented that, have naively updated the English man page and usage message, and was about to amend this PR, when it dawned on me that, as a consequence of the change, 57 .po files awaited further attention. While the language support is truly impressive, it makes me shy back at this point.

I don't think that the improvement this PR presents would justifiy the effort. But out of interest for your workflow: How should contributions ideally be made in the face of this immense fallout? Is there some release cycle one should adhere to? Development branches PRs should be rebased against?