Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1607194 - conflicts between filesystem and several packages
Summary: conflicts between filesystem and several packages
Alias: None
Product: Fedora
Classification: Fedora
Component: python-rpm-macros
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-07-23 00:56 UTC by George R. Goffe
Modified: 2018-07-26 04:08 UTC (History)
9 users (show)

Fixed In Version: sugar-toolkit-0.112-5.fc29, python-httplib2-0.11.3-5.fc29, python-optcomplete-1.2-0.19.20130428hg9583af7.fc29, denyhosts-2.10-15.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-07-24 22:06:03 UTC

Attachments (Terms of Use)

Description George R. Goffe 2018-07-23 00:56:42 UTC
Description of problem:
Attempting to upgrade this system produces conflict messages for other packages and the filesystem package (sugar-toolkit-0.112-4.fc29.x86_64 python2-httplib2-0.11.3-4.fc29.noarch python2-optcomplete-1.2-0.18.20130428hg9583af7.fc29.noarch denyhosts-2.10-14.fc29.noarch)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1./usr/bin/dnf --best --refresh --skip-broken --allowerasing upgrade

Actual results:
see below

Expected results:
A clean AND functional system with all installed packages at the proper levels

Additional info:

Error: Transaction check error:
  file /usr/lib from install of sugar-toolkit-0.112-4.fc29.x86_64 conflicts with file from package filesystem-3.9-2.fc29.x86_64
  file /usr/lib from install of python2-httplib2-0.11.3-4.fc29.noarch conflicts with file from package filesystem-3.9-2.fc29.x86_64
  file /usr/lib from install of python2-optcomplete-1.2-0.18.20130428hg9583af7.fc29.noarch conflicts with file from package filesystem-3.9-2.fc29.x86_64
  file /usr/bin from install of denyhosts-2.10-14.fc29.noarch conflicts with file from package filesystem-3.9-2.fc29.x86_64
  file /usr/lib from install of denyhosts-2.10-14.fc29.noarch conflicts with file from package filesystem-3.9-2.fc29.x86_64

Comment 1 Kamil Dudka 2018-07-23 09:45:03 UTC
I guess this is a problem in the other packages that try to install /usr/lib and /usr/bin by mistake because %{python_sitelib} now evaluates to an empty string.

See for example bug #1603161 where a trivial fix is proposed for python2-bootle.

I am switching the component to python-rpm-macros as it seems to be the cause of this breakage.

Comment 2 Miro Hrončok 2018-07-23 10:16:48 UTC
Those macros are defined in the rpm package, not python-rpm-macros. Yet it is the bug of the packages not following the guidelines.

A fix has been proposed:





Except python2-httplib2, the maintainers seem not to care (or are absent).

Comment 3 Kamil Dudka 2018-07-23 10:26:46 UTC
Could you please make sure that %{python_sitelib} gets undefined?

Currently, it is (IMO by mistake) defined as an empty string, which causes the "broken" packages to build successfully but the build produces binary packages that cannot be installed.

If you make sure that %{python_sitelib} is undefined, it will prevent the "broken" packages from being built until they are fixed.

Comment 4 Miro Hrončok 2018-07-23 10:33:25 UTC

Comment 5 George R. Goffe 2018-07-24 22:17:06 UTC

Why is this bug report closed? Is it fixed? Is a fix on the way?


Comment 6 Miro Hrončok 2018-07-24 22:41:02 UTC
It was fixed in sugar-toolkit-0.112-5.fc29, python-httplib2-0.11.3-5.fc29, python-optcomplete-1.2-0.19.20130428hg9583af7.fc29, denyhosts-2.10-15.fc29

Comment 7 Jason Tibbitts 2018-07-24 22:43:30 UTC
The underlying issue about %python_sitelib being defined and completely empty is not solved as far as I know.  That's going to have to work its way down from upstream RPM.

Of course, this bug is completely misfiled anyway, since python-rpm-macros doesn't define these macros, and cannot do so without conflicting with what RPM itself does.  So if someone is going to reopen it, please change the component properly.

Comment 8 George R. Goffe 2018-07-25 04:06:55 UTC

How does one find out who owns the component a bug report is filed again?


Comment 9 Jason Tibbitts 2018-07-25 15:47:14 UTC
Packages are not "owned" in Fedora.

If you want to know who maintains a package, you can go to

If you want to email the maintainers of a package, that is  (Yeah, it says "owner"; we're fixing that so you can use "-maintainers" as well.)

If you just want to make sure that a bugzilla ticket is assigned correctly, it will offer to reset the various assignees when the component is changed.  Just make sure the relevant checkboxes are checked.

Comment 10 George R. Goffe 2018-07-26 04:08:11 UTC

Thanks for your information. I'll try to make better bug reports.

Again, Thanks,


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