Bug 1219638 - DNF doesn't use xml:base in repodata
Summary: DNF doesn't use xml:base in repodata
Status: CLOSED DUPLICATE of bug 1257965
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
(Show other bugs)
Version: 21
Hardware: All Linux
unspecified
unspecified
Target Milestone: ---
Assignee: packaging-team-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
: 1245286 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-07 20:57 UTC by fedora.dm0
Modified: 2016-05-30 11:40 UTC (History)
12 users (show)

Fixed In Version: dnf-plugins-core-0.1.10-1.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-30 11:40:40 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
repomd.xml (1.35 KB, text/plain)
2015-05-07 20:57 UTC, fedora.dm0
no flags Details
primary.xml (3.51 KB, text/plain)
2015-05-07 20:58 UTC, fedora.dm0
no flags Details

Description fedora.dm0 2015-05-07 20:57:04 UTC
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.

Comment 1 fedora.dm0 2015-05-07 20:58:32 UTC
Created attachment 1023267 [details]
primary.xml

Note the location element.

Comment 2 Honza Silhan 2015-07-22 11:30:28 UTC
*** Bug 1245286 has been marked as a duplicate of this bug. ***

Comment 3 Adam Williamson 2015-07-22 15:52:07 UTC
To make it clear why this is nominated as an Alpha blocker, according to dgilmore in the dupe it breaks image compose.

Comment 4 Radek Holy 2015-07-23 05:28:25 UTC
Let's also repeat my concern: There is no documentation of that xml:base attribute whose presence causes DNF to supposedly block Fedora.

Comment 5 Radek Holy 2015-07-23 05:32:31 UTC
...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.

Comment 6 Adam Williamson 2015-07-27 16:26:02 UTC
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.

Comment 7 Honza Silhan 2015-08-04 08:00:34 UTC
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).

Comment 8 Adam Williamson 2015-08-04 22:19:20 UTC
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.

Comment 9 Honza Silhan 2015-08-07 10:25:21 UTC
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)

Comment 10 Fedora Update System 2015-08-10 10:05:22 UTC
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

Comment 11 Fedora Update System 2015-08-10 10:49:27 UTC
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

Comment 12 Fedora Update System 2015-08-11 02:10:40 UTC
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).

Comment 13 Fedora Update System 2015-08-15 02:13:43 UTC
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.

Comment 14 Fedora Update System 2015-08-19 07:51:11 UTC
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.

Comment 15 Dennis Gilmore 2016-02-29 19:30:29 UTC
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.

Comment 16 Anthony Messina 2016-05-24 19:30:17 UTC
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

Comment 17 Anthony Messina 2016-05-24 19:32:00 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=1338928

Comment 18 Michal Luscon 2016-05-30 11:40:40 UTC

*** This bug has been marked as a duplicate of bug 1257965 ***


Note You need to log in before you can comment on or make changes to this bug.