On 2012-12-06 02:12, Stephen J. Turnbull wrote: > I understand the PEP author's frustration with continued discussion, > but I think this subthread on Obsoletes vs. Obsoleted-By is not mere > bikeshedding on names. It matters *which package* presents the > information. > > > Donald Stufft writes: > > On Wednesday, December 5, 2012 at 6:18 PM, Barry Warsaw wrote: > > > On Dec 05, 2012, at 06:07 PM, Donald Stufft wrote: > > > > > > > If you're installing B you've prescribed trust to that > > > > author. If you don't trust the author then why are you > > > > installing (and then executing) code they wrote. > > The author may be a genius when it comes to writing code, and an idiot > when it comes to distributing it. Distribution is much harder than it > looks, as you know. Trusting the author's *content* and trusting the > author's *metadata* are not equivalent! > > As far as I can see, the semantics of putting "Obsoletes: A" into B > without changing A are the same as the semantics of putting "Provides: > A" into B (without changing A).[1] Only if A includes "Obsoleted-By: B" > can a user be confident that B is a true successor to A. > > Furthermore, as has been pointed out, the presence of "Obsoleted-By" > in A has the huge advantage of informing users and developers of > dependent packages alike that A is obsolete when they try to update A. > If A is not changed, then an attempted update will tell them exactly > that, and they may never find out about B. But if A is modified in > this trivial way, the package system can automatically inform them. > This is also trivial, requiring no database queries. > > "Simple is better than complex." > That makes sense. In summary, someone using B won't care that it has replaced A, but someone using A needs to be told that it has been replaced by B.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4