Created attachment 1023266 [details] repomd.xml Description of problem: If you run createrepo with --outputdir and --baseurl to write repodata outside the RPMs' directory, dnf ignores the specified --baseurl. The equivalent commands work with yum. Version-Release number of selected component (if applicable): 0.6.5 How reproducible: Always Steps to Reproduce: cd /tmp mkdir rpms repo yumdownloader --destdir rpms --enablerepo=rawhide filesystem createrepo_c --no-database --simple-md-filenames --outputdir repo --baseurl "file://$PWD/rpms" rpms sudo dnf --config=/dev/stdin --disablerepo=* --enablerepo=demo <<< "$(cat /etc/dnf/dnf.conf ; echo -e "[demo]\nname=Demo\nbaseurl=file://$PWD/repo\ngpgcheck=0\nmetadata_expire=0")" -y upgrade filesystem Actual results: ... Downloading Packages: [Errno 2] No such file or directory: u'/tmp/repo/filesystem-3.2-32.fc23.x86_64.rpm' Expected results: It should download and install the package from /tmp/rpms/, not /tmp/repo/. (Replace "dnf" with "yum" and "/etc/dnf/dnf.conf" with "/etc/yum.conf" in the last command, and it succeeds.) Additional info: I've attached the generated repomd.xml and primary.xml.gz (decompressed). You can see that xml:base is set to the --baseurl value on the RPM's location element, but dnf apparently isn't using it.
Created attachment 1023267 [details] primary.xml Note the location element.
*** Bug 1245286 has been marked as a duplicate of this bug. ***
To make it clear why this is nominated as an Alpha blocker, according to dgilmore in the dupe it breaks image compose.
Let's also repeat my concern: There is no documentation of that xml:base attribute whose presence causes DNF to supposedly block Fedora.
...let's hope that createrepo does not come with another undocumented attribute tomorrow... Anyway, I find it a bit unfair that someone ports something to DNF without proper testing and later then DNF is accused of blocking Fedora.
Discussed at 2015-07-27 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-07-27/f23-blocker-review.2015-07-27-16.00.log.txt . As things stand, this bug has been addressed by dgilmore by applying a downstream patch in the dnf package: http://pkgs.fedoraproject.org/cgit/dnf.git/commit/?h=f23&id=85b88dbcae49712956c869dd27b09fdbf9fa5ec3 so for Fedora purposes the bug is fixed. We have a process problem, though, because dnf team is using this Bugzilla as their upstream bug tracking system. The bug is now fixed downstream (in Fedora) but not upstream (in dnf). So whether we close it or leave it open, it is wrong from one of those perspectives. Ideally, if DNF wants to use RH Bugzilla as its upstream bug tracker, it should have its own product, so we don't have this problem. dgilmore still wants the bug open to try and have this resolved properly upstream, so for the purposes of the blocker process we must remove blocker status from the bug as it's addressed downstream. Note however that in substance the bug remains a blocker, and if the fix disappears from the package for any reason, the blocker status may be reinstated without further review.
We are aware of the downstream patches. So far dgilmore's patches are in F23 and rawhide. Right, this bug tracks the merge of downstream patches into the upstream. If they doesn't cause any regression they will be merged into the upstream in the next dnf release (dnf-1.0.3).
Jan: The thing is, Fedora Bugzilla is for Fedora, and it's used for other Fedora purposes, like blocker bug tracking. When you're using the same Bugzilla component for upstream and downstream bug tracking, it is inevitably going to cause confusions like this. It'd make things substantially clearer to separate upstream and downstream bug tracking.
ok, the only difference is with downstream patches directly applied in dist-git. Otherwise the bug is closed by Fedora upgrade system once it's in updates (not merged in the upstream). Having patched just downstream happens rarely in DNF and we can track these downstream -> upstream patch applications separately next time. (the patch has been merged in the upstream)
dnf-plugins-core-0.1.10-1.fc23,dnf-1.1.0-1.fc23,hawkey-0.6.0-1.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.10-1.fc23,dnf-1.1.0-1.fc23,hawkey-0.6.0-1.fc23
dnf-plugins-core-0.1.10-1.fc22,dnf-1.1.0-1.fc22,hawkey-0.6.0-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.10-1.fc22,dnf-1.1.0-1.fc22,hawkey-0.6.0-1.fc22
Package dnf-plugins-core-0.1.10-1.fc22, dnf-1.1.0-1.fc22, hawkey-0.6.0-1.fc22: * should fix your issue, * was pushed to the Fedora 22 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.1.10-1.fc22 dnf-1.1.0-1.fc22 hawkey-0.6.0-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-13162/dnf-plugins-core-0.1.10-1.fc22,dnf-1.1.0-1.fc22,hawkey-0.6.0-1.fc22 then log in and leave karma (feedback).
dnf-plugins-core-0.1.10-1.fc22, hawkey-0.6.0-1.fc22, dnf-1.1.0-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
dnf-plugins-core-0.1.10-1.fc23, hawkey-0.6.0-1.fc23, dnf-1.1.0-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
I recieved an email today saying that the patch for this is going to be removed http://lists.baseurl.org/pipermail/yum/2013-March/023935.html talks about xml:base it is something that has been around a long time and perhaps has not been well documented but is expected to work.
This also happens in Fedora 24 where DNF fails to download packages from external repositories using Koji's merged primary.xml: https://pagure.io/koji/issue/85
See https://bugzilla.redhat.com/show_bug.cgi?id=1338928
*** This bug has been marked as a duplicate of bug 1257965 ***