Open dschwoerer opened 2 months ago
I can reproduce this issue, e.g. with dnf5 install -y blender
and dnf5 install -y hello
.
DNF 4 is not affected by this bug; the second DNF 4 process will wait until the first DNF 4 process has finished before starting to download RPMs for its transaction.
dnf5 should either not start another instance, or it should not delete the cache files of a different, running instance.
I'd prefer if DNF 5 took the same approach that DNF 4 does. The implementation will likely be simpler and we will not stress the mirrors by having multiple DNF 5 processes try to download at once.
As a user with a slow download link, I can start
dnf5 install big-package(s)
While the download is running, I realise I also need another package:dnf5 install small-package
Then the second instance finishes the download first, and after a successful transaction deletes all the files, which in turn breaks the first instance.dnf5 should either not start another instance, or it should not delete the cache files of a different, running instance.
This is especially annoying as downloading some big packages with many dependencies can take quite some time, and installing a small script requires a new attempt. If I remember correctly the download keeps running, but the install fails afterwards.