Robert Haas <robertmhaas@gmail.com> writes:
> So the idea is that you're actually supposed to separately catalog
> each feature you added (e.g. each new function), so that people can
> depend specifically on those features.
> I don't really have the foggiest idea how people using other packaging
> systems handle this. It seems like it would be a huge pain in the
> rear end to be continually adding Provides: lines to RPMs for every
> new feature that a new version of a package offers, not to mention
> that you'd hardly want the corresponding Requires: lines to have to
> enumerate all the public interfaces those packages used just in case
> one of them ever went away. I have a feeling I'm missing part of the
> picture here, somehow.
Yeah. AFAIK, nobody actually does that. In my experience with Red Hat
packages, so-called "virtual Provides" (which are exactly equivalent to
this proposed feature) are used only for cases where there is or is
planned to be more than one package that can supply a given API, and the
Provides is really more of a logical package name than an identifier of
a feature as such. When people want to depend on a feature that was
added after initial release of a package, they invariably use
versioned dependencies like "Requires: foobar >= nnn". And it's also
pretty common to use such a dependency because you need to have a bug
fixed that was fixed in version nnn; so assuming that you only need
feature names for, er, features may be a mistake too.
So if you look at common practice, this whole idea is wrong and we ought
to define a way to compare version numbers instead. I'm not entirely
sure that I want to go there yet, but it certainly bears considering as
a time-tested alternative design.
regards, tom lane
