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:
> http://www.python.org/dev/peps/pep-0426/#provides-dist-multiple-use
> 
> 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 version
> like this:
> 
> Provides: python
> Provides: python = 3.1.0
> 
> rpm has no way at package build time to tell that a particular name given in
> a provides in one package is the actual name of another package.
> 
> At installtime, rpm keeps package names and provides names separately but in
> dependency 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 and
> 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 requirement.
> 
Are you saying the RPM documentation is wrong? 

http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html

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
installed.

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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to