rpm-software-management / dnf

Package manager based on libdnf and libsolv. Replaces YUM.
GNU General Public License v2.0
1.22k stars 405 forks source link

Allow local downloads to same `downloaddir` #2106

Closed nicbadiu closed 2 weeks ago

nicbadiu commented 3 weeks ago

Currently when dnf download --downloaddir <dir> <package> sources<package> from <dir> it triggers a shutil.SameFileError exception and aborts the entire download process with a '<package>.rpm' and '<package>.rpm' are the same file error.

This goes against the current flow which marks locally present RPMs that match a remote RPM as [SKIPPED] <package>.rpm: Already downloaded.

This change allows downloads of locally sourced packages to the same file, treating it as a no-op.

nicbadiu commented 2 weeks ago

Many thanks for approving and checking this behavior in the newer version - we will look into moving to dnf5 - it is good to know we do not need to retain a workaround after upgrading.

The situation we are dealing with is two RPM-interdependent systems that are expected to both place and source their RPM artifacts using the same directory in order to reduce duplication, code complexity, and ordering (race conditions) runtime issues.

If we did not use a single directory for both systems then we would need to have a DNF-like synchronization mechanism between three different locations (one for each system and the local repository directory itself, which is consumed by external systems).

When either of the systems produces a newer version of an RPM, DNF download will pick the local repository version and that is when we see the ‘same file’ issue.

As a short-term solution, for a subset of the RPMs for one of the systems we use a separate directory and we sync that with the main (local repository) directory based on the header signature of the RPMs.

Thanks, Nic

On Jul 2, 2024, at 10:57 AM, Marek Blaha @.***> wrote:

@m-blaha approved this pull request.

Purely out of curiosity - would you mind describing your use case that hits this exception? Downloading a package from a back to the same location seems a bit strange to me. Btw dnf5 (replacing dnf in F41) seems to work correctly here, marking the local package being downloaded as Already downloaded.

— Reply to this email directly, view it on GitHub https://github.com/rpm-software-management/dnf/pull/2106#pullrequestreview-2152996756, or unsubscribe https://github.com/notifications/unsubscribe-auth/BA5VVYP7QEOHJAF7QBIX2FLZKJMNRAVCNFSM6AAAAABKBRV2E6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCNJSHE4TMNZVGY. You are receiving this because you authored the thread.

nicbadiu commented 2 weeks ago

Any idea why check https://artifacts.dev.testing-farm.io/dbe646e2-d7a0-4ae6-9bc3-1e3feab1654c/ is failing? The only scenario the proposed code changes would fail is in a negative test, whereas this failure is during setup.

testing-farm:fedora-rawhide-x86_64:dnf-tests — Test environment installation failed: Install packages