Rpm uses fewer requirements "tags" like Requires: and BuildRequires:
(the vastly common ones) plus other less frequently used like PreReq:
Provides: Conflicts: BuildConflicts: BuildPreReq: etc.
The BuildConflicts: I never seen a user case for it personally, the
Provides: and Conflicts: on non-distrubution packages should not be used
(aka. they will have an impacted on other applications).
They are clearly separated between the build stage (that is highly
likely to be done by a non root user) and the install stage that has to
be done at administrator level: the latter requires a deep knowledge of
software life cycle to integrate properly without breaking things.
On a side note rpm's been around for decades and it is an industry
standard for linux.
I hope this helps.
Daniel Holth wrote:
On Mon, Feb 11, 2013 at 10:18 PM, Daniel Holth <dho...@gmail.com
<mailto:dho...@gmail.com>> wrote:
On Mon, Feb 11, 2013 at 1:37 PM, Marcus Smith <qwc...@gmail.com
<mailto:qwc...@gmail.com>> wrote:
>> Projects which wish to use non-compliant version identifiers
must restrict themselves to metadata v1.1
currently, "Projects" don't have control over this, right?
setuptools/distutils just writes 1.0 or 1.1 metadata, period.
maybe that can be clarified for me and others.
what can a project really do right now to use v1.3? nothing,
except wait for tool chain updates?
I've taken the language out. Wacky versions will not sort correctly with
installers no matter which metadata is being used and you don't really
get to choose your metadata version.
Setup-Requires-Dist doesn't need to support extras aka Provides-Extra
aka optional features. It would have been a new feature and would
probably cause trouble with workflows like "setup [extras] build a
binary package" and then "install [with different extras] the binary
package"
Provides-Dist does not need to repeat the project's name. Does RPM do
this? If you are writing Metadata 1.3 by hand it would just feel silly
to type the name twice.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
