Attention, Extras packagers! [on Upgrades + Obsoletes]

[Michael Schwendt]

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".