[Python-Dev] Accept just PEP-0426
ncoghlan at gmail.com
Tue Nov 20 03:01:58 CET 2012
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.
Sent from my phone, thus the relative brevity :)
On Nov 20, 2012 11:45 AM, "Donald Stufft" <donald.stufft at gmail.com> wrote:
> 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 OS
> managers which have it don't allow it to be used to masquerade
> as 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 only
> just 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
> like this:
> Provides: python
> Provides: python = 3.1.0
> rpm has no way at package build time to tell that a particular name given
> a provides in one package is the actual name of another package.
> At installtime, rpm keeps package names and provides names separately but
> dependency comparisons either one can be used to satisfy a requirement.
> What that means is that when asking about information on a package with
> "python", you'll get information about the python package with that name
> not about anything else that Provides: "python". But if you are installing
> something that has a requirement on "python" either the package with the
> name python or any package that Provides: python can satisfy the
> Are you saying the RPM documentation is wrong?
> The provides tag is used to specify a *virtual package* that the packaged
> software makes available when it is installed. Normally, this tag would be
> used when different packages provide equivalent services. For example,
> any package that allows a user to read mail might provide the mail-reader
> virtual package. Another package that depends on a mail reader of some
> sort, could require the mail-reader virtual package. It would then install
> without dependency problems, if any one of several mail programs were
> It pretty clearly states that it is not to be used for masquerading as a
> different package, which was my point. I wasn't making any claims about
> wether it was technically possible to do so or not, just what it's intended
> purpose was.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev