[Python-Dev] Keyword meanings [was: Accept just PEP-0426]
a.badger at gmail.com
Wed Dec 5 16:42:48 CET 2012
On Wed, Dec 05, 2012 at 02:46:11AM -0500, Donald Stufft wrote:
> On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:
> On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth <dholth at gmail.com> wrote:
> How to use Obsoletes:
> The author of B decides A is obsolete.
> A releases an empty version of itself that Requires: B
> B Obsoletes: A
> The package manager says "These packages are obsolete: A". Would you
> like to
> remove them?
> User says "OK".
> Um, no. Even if the the author of A and B are the same person, you
> can't remove A if there are other things on the user's system using
> it. The above scenario does not work *at all*, ever, except in the
> case where B is simply an updated version of A (i.e. identical API) --
> in which case, why bother? To change the project name? (Then it
> should be "Formerly-named" or something like that, not "Obsoletes".)
> You can automatically uninstall A from B in an automatic dependency
> management system. I *think* RPM does this, at the very least
This is correct.
> I believe it refuses to install B if A is already there (and the reverse
> as well).*
I'd have to test this but I believe you are correct about the first. Not
sure about the reverse.
> There's nothing preventing an installer from, during it's attempt to
> install B, see it Obsoletes A, looking at what depends on A and
> warning the user what is going to happen and prompt it.
In rpm-land, if something depended on A and nothing besides the actual
A package provided A, rpm will refuse to install B. But rpm is meant to be
used unattended so different package managers could certainly choose to
prompt. For package renames, package B would have both an Obsoletes: A <=
$OLD_VERSION and a Provides: A = NEW_VERSION
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Python-Dev