Bug 910133

Note that RPM behaves the same way, it first downloads and then tries to perform the transaction:

[akozumpl@aklap ~]$ rpm -iv http://akozumpl.fedorapeople.org/t.new/mystery-devel-19.67-1.noarch.rpm
Retrieving http://akozumpl.fedorapeople.org/t.new/mystery-devel-19.67-1.noarch.rpm
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied)

Which makes a lot of sense because we can never now in advance whether the user is going to have the permissions to perform the transaction once we're finished downloading the packages and shouldn't assume he won't just because he doesn't at the moment when the downloads start.

Closing this as NOTABUG.

How is it possible for dnf to have permissions to install if it doesn't when dnf starts downloading?  Besides, RPM is typically dealing with one download at a time but dnf is typically dealing with multiple (the current RPM behavior of saying permission denied comes after a bug report by me fyi).  Besides, you are throwing away all the downloaded data and redownloading them all which is certainly a problem for users.

(In reply to comment #2)
> How is it possible for dnf to have permissions to install if it doesn't when
> dnf starts downloading? 

because the download doesn't happen as an atomic operation on the system, something can grant/revoke the rpm transaction privileges in the meantime. There's no point checking things in advance if they can change.

> Besides, you are throwing away all the downloaded data and redownloading
> them all which is certainly a problem for users.

But what else is there to do? The main dnf cache can not be writable by regular user, he could spoof package for installation into there.

I don't think in practice it does really change and checking in advance makes sense and that's what the expected behavior is as seen in other dependency resolvers including yum, apt etc.  I will just stop with voicing my objection to this decision.

*** Bug 973510 has been marked as a duplicate of this bug. ***

Hi Ales,

I've seen a few users confused by this behaviour. If a certain operation cannot be carried out as a non root user, it's better to just stop the command right there. Downloading metadata makes them think that the command is running, and they're quite taken aback with the "don't have permissions" error later. Can you please reconsider this behaviour? 

Like Rahul's said, it may be possible that the permissions change, but I really doubt it's going to happen when using the dnf command line, or other frontends that may come up in the future. 

I see that this isn't required technically, but it's a usability issue here. 

Thanks,
Ankur

Hi, it is really a weird behaviour, that confused me. And i think it is not right to download files if it can't install them. If i pay for my connection it consumes a lot of MB or GB for nothing.

Thanks

Let me assure you again this is the standard behavior of many other linux apps: unless the app runs into a call that returns permissions etc. error it just keeps on executing whatever it set out to do. It's not a good idea to be trying to guess up front whether or not a particular operation will succeed, in many cases it is not even realistically possible (see comment 3). Besides, I personally know of many users who appreciate that DNF doesn't treat non-root users as special.

Closing this again. Once the plugin API is stabilized and the documentation published people will be able to write a simple plugin that does exactly what this bug is suggesting. For the time being I don't see anybody from the regular DNF contributors (planning to be) working on a plugin like that (speak up if you do).

I would really be disappointed if I start copying 300 TiB of data to an external hard drive, and I get the error "no more space" at 90%.
I have exactly the same feeling here. It starts processing, and them throw you away with this permission error.

It's not because other app works that way that it's the best way.

Either checking permission before and let the user getting privilege *now*, or getting the root privilege letter would be fine.
What prevent to log as root once dnf has found that you don't have root access?

reopening by popular demand. this will be provided as a plugin.

*** Bug 1038504 has been marked as a duplicate of this bug. ***

*** Bug 1044995 has been marked as a duplicate of this bug. ***

this is provided by the current dnf-plugins-core release, install it with:

$ dnf install dnf-plugins-core

and from then on, operations potentially trying to modify rpmdb will stop early.

*** Bug 1053676 has been marked as a duplicate of this bug. ***

Will this plugin be installed and enabled by default?

*** Bug 1066747 has been marked as a duplicate of this bug. ***

*** Bug 1069384 has been marked as a duplicate of this bug. ***

(In reply to jpacner from comment #15)
> Will this plugin be installed and enabled by default?

No, the user has to install dnf-plugins-core, then it's enabled.