Look more closely at the docs for "Obsoletes" in RPM, not just those for "Provides". Being able to transparently replace an existing package with a renamed one that installs files with the same names is certainly part of the purpose/capabilities of the RPM dependency machinery (i.e. precisely the distribute vs setuptools situation).
We may want to clarify the wording to ensure it is clear that the provision of the dist name (as posted on PyPI) is implied, though.
Cheers,
Nick.
--
Sent from my phone, thus the relative brevity :)
On Monday, November 19, 2012 at 8:35 PM, Toshio Kuratomi wrote:On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote:Other languages seem to get along fine without it. Even the OSmanagers which have it don't allow it to be used to masqueradeas another project, only to make generic virtual packages (e.g. "email").I'm not sure this assertion about OS package managers is correct. I've onlyjust read:but the rough rpm analogue seems to be the Provides: tag.Provides is given a string which is parsed into a name or a name and versionlike this:Provides: pythonProvides: python = 3.1.0rpm has no way at package build time to tell that a particular name given ina provides in one package is the actual name of another package.At installtime, rpm keeps package names and provides names separately but independency comparisons either one can be used to satisfy a requirement.What that means is that when asking about information on a package with name"python", you'll get information about the python package with that name andnot about anything else that Provides: "python". But if you are installingsomething that has a requirement on "python" either the package with thename python or any package that Provides: python can satisfy the requirement.Are you saying the RPM documentation is wrong?The provides tag is used to specify a *virtual package* that the packagedsoftware makes available when it is installed. Normally, this tag would beused when different packages provide equivalent services. For example,any package that allows a user to read mail might provide the mail-readervirtual package. Another package that depends on a mail reader of somesort, could require the mail-reader virtual package. It would then installwithout dependency problems, if any one of several mail programs wereinstalled.It pretty clearly states that it is not to be used for masquerading as adifferent package, which was my point. I wasn't making any claims aboutwether it was technically possible to do so or not, just what it's intendedpurpose was.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com