Seeing how the Fedora Extras Broken Dependencies reports have grown larger for some time, I believe some education is needed. Forgive me for calling it "education", but particularly the first issue really appears to be something that is not known widely yet: ==== When eliminating sub-packages in a spec file, regardless of whether it's done with or without a corresponding "Obsoletes: ..."/"Provides: ..." pair of tags, old binary builds will NOT disappear from the repository automatically. They become _binary orphans_, since no new builds of your packages will cause the old builds to be purged from the repository by an automated clean-up job. Yum and other tools like repoview and createrepo -- in the following I will write just "Yum" -- will still see these old packages in the repository. With Yum our users will still be able to install these obsolete packages as long as the RPM transaction succeeds. Else the user will encounter broken dependencies during installation or during a future update. During installation of a package, Yum sees ALL packages in the repository prior to creating the transaction set. Together with dependencies on specific versions of other packages, which have been upgraded meanwhile and are no longer available, the transaction would fail even more badly. Repoview and "yum list" also see and advertise all packages, including obsolete ones. || You need to request that the repository maintainers delete these || old/obsolete sub-packages! There is a related bug report about Yum (http://bugzilla.redhat.com/190116), since it's non-intuitive that "yum install foo" does not fetch the package which provides the highest version of "foo". Examples: 1) You have "foo" and "foo-devel" built and published. In an update, you eliminate and obsolete "foo-devel" and publish the new "foo". "foo-devel" will remain in the repository even if you make your new package "Provides: foo-devel = %{version}-%{release}" with version-release being higher than before. A "yum install foo-devel" will take your old foo-devel package and will usually fail badly in the transaction (because -devel packages depend on a specific version of their mother package). 2) You have "foo" and "foo-emacs" built and published. In an upgrade, support for Emacs is gone. First of all, this would be regression and should be avoided. But if you simply eliminate the "foo-emacs" package, the old binary builds will remain in the package repository. Forever. If they depend on other packages which are still available, too, even if it's older versions, users may still be able to install all this old stuff with "yum install foo-emacs". With the next upgrade: *boom* For instance, if any dependencies are upgraded/changed and a way which gets incompatible with the old sub-package which should have been deleted. ==== Further, we've had a couple of ABI breaking upgrades so far. Not just due to SONAME changes, but due to ordinary _major version upgrades_. Where apparently the package maintainers didn't talk to eachother despite the fact that ABI upgrades (in everything other than Fedora Extras Development) should be avoided like the plague. || When a package NEV (name-epoch-version) or NEVR || (name-epoch-version-release) is hardcoded as a dependency, || inform your fellow package maintainer about this strict dependency! Example: 1) Your package "foo" depends on a specific version of "bar", and you use a "Requires: bar = 2.0-1" tag for this. First of all, the reason for this strict dependency must be documented in the spec file. Secondly, the maintainer of "bar" must be informed about this package relationship, so any version upgrades of bar are coordinated properly with the packager of "foo".
