[Python-Dev] Keyword meanings [was: Accept just PEP-0426]
ncoghlan at gmail.com
Thu Dec 6 05:54:45 CET 2012
On Thu, Dec 6, 2012 at 1:12 PM, Daniel Holth <dholth at gmail.com> wrote:
> Makes sense. How about calling it Replacement. 0 or 1?
Hah, you'd think I'd have learned by now to finish reading a thread before
replying. It will be nice to get this addressed along with the other
(FWIW, Conflicts and Obsoletes are messy in RPM as well, and especially
troublesome as soon as you start enabling multiple upstream repos from
different providers. The metadata problem is handled by prebuilding indices
when the repo changes, but that's still more work for the server, and more
work for clients)
> Replacement (optional)
I like verb forms like Obsoleted-By or Replaced-By, as the noun form is
ambiguous about the direction of the change. Since the field being replaced
is Obsoletes, Obsoleted-By makes sense.
> Indicates that this project is no longer being developed. The named
> project provides a drop-in replacement.
Typically, the new version *won't* be a drop-in replacement (e.g. you'll
likely at least have to import from a different top level package).
Instead, the field would more often be used as an explicit indicator that
the project is no longer receiving updates, as the *development team* has
moved on, so users may want to consider either migrating, taking over
development (if the former developers are amenable) or forking.
If the replacing project *is* a drop-in replacement for the old project,
then it should also advertise a Provides-Dist for the original project.
Automated tools can then easily detect the two cases:
A Obsoleted-By-Dist B and B Provides-Dist A = A is defunct, and B should be
a drop-in replacement for A
A Obsoleted-By-Dist B (without a Provides-Dist on B) = A is defunct, B is a
replacement for A, but some porting will be needed
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev