From Fedora Project Wiki

Remove python-setuptools-devel


The python-setuptools package has carried a virtual Provide for python-setuptools-devel since 2009 for backwards compatibility. We're going to remove this virtual Provide. Packages which still BuildRequire python-setuptools-devel will need to be updated to Require: python-setuptools instead.


Current status

Detailed Description

In November of 2009, in time for Fedora 13, we solved a packaging issue in the main python package that allowed us to remove a split in our python-setuptools package. Instead of needing a separate python-setuptools-devel subpackage for easy_install the python-setuptools package could now contain all of the functionality of python-setuptools. To ease with package migration we added an Obsoletes and Provides tag to the python-setuptools package at that time so that packages, kickstarts, etc which required python-setuptools-devel would not break.

Fast forward to the present day:

It's December of 2013. Rawhide is Fedora 21. I'd like to drop the backwards compatibility Provides (and Obsoletes) from the python-setuptools package. However, there are currently 151 packages BuildRequire'ing python-setuptools-devel. This Change exists to make people aware that they need to update their packages.

Benefit to Fedora

Remove old cruft and clean up the packaging namespace a tiny bit.


  • Proposal owners: Remove the Provides: and Obsoletes: python-setuptools-devel in the python-setuptools package and rebuild. This will take approximately 30 minutes.
  • Other developers: Owners of packagers that BuildRequire: python-setuptools-devel need to change to BuildRequire: python-setuptools and rebuild. Individually, this takes approximately 30 minutes per package (but largely waiting on builds to finish successfully). There are approximately 151 packages in the
  • Release engineering: No action needed by rel-eng. Until other developers update their BuildRequires, their packages would fail to rebuild in a mass rebuild.
  • Policies and guidelines: No action needed. The packaging guidelines have already been changed to use BuildRequires: python-setuptools rather than python-setuptools-devel.

Upgrade/compatibility impact

No impact for most users. If users have home-grown packages installed, they could have included Requires and BuildRequires that reference python-setuptools-devel instead of python-setuptools. But this is no different than any other package name that is dropped from the distribution.

How To Test

All of the following repoqueries should return nothing:

repoquery -q --disablerepo='*' --enablerepo=fedora --enablerepo=updates --whatprovides python-setuptools-devel --releasever=rawhide
repoquery -q --disablerepo='*' --enablerepo=fedora --enablerepo=updates --whatrequires python-setuptools-devel --releasever=rawhide
repoquery -q --disablerepo='*' --enablerepo=fedora-source --enablerepo=updates-source --archlist=src \
    --whatrequires python-setuptools-devel --releasever=rawhide

The repoqueries should function from any machine that has repoquery and a connection to the yum repos for rawhide. The releasever will change to f21 once rawhide branches.

User Experience

This should not be noticable to end users.


Nothing blocks us from removing the backwards compatibility in the python-setuptools package now.

Packages which BuildRequire python-setuptools-devel will no longer build until they update their dependency to BuildRequire: python-setuptools.

List of the 151 packages needing fixing

Contingency Plan

If all packages are not switched from BuildRequiring python-setuptools-devel we'll have several choices:

  • Drop the packages that have not ported. This would be my preference if all the packages that are unported have been examined and FTBFS for a separate reason.
  • Ship with the last successful build of the unported packages. If there's no mass rebuild for python packages this release then the last packages built with the old Requires should still work at runtime (I've already fixed all packages that Require: python-setuptools-devel. It's only packages which BuildRequire it that need to be fixed). This is deferring the pain until a rebuild of the package is required but the change to fix this at that time is quite simple.
  • Re-add the python-setuptools-devel Provides and Obsoletes to the python-setuptools package. This would not be my choice unless some unforeseen circumstance makes us realize that the python-setuptools-devel alias is important to something other than broken BuildRequires.
  • Contingency deadline:
    • If we went with dropping packages as the contingency it should be done early. Doing this along with the mass orphaning that happens every cycle seems like the right time. (prior to rawhide branching.)
    • If we went with shipping the last successful build there's really nothing that needs to be done.
    • If we re-added python-setuptools-devel to the package it could be done quite late. Beta freeze or even later if QA wouldn't kill me.
  • Blocks release? No


No documentation needed.

Release Notes

Release notes not needed.