PEP440 "Local versions" idea in rpm/deb?
PEP440 has the "local version" idea to distinguish locally patched projects from upstream versions. http://legacy.python.org/dev/peps/pep-0440/#local-version-identifiers e.g. Django-1.6.4-1 for a locally patched Django-1.6.4 to place on a local index. Although it doesn't relate directly to this list, I know Nick (the PEP440 author) works with Redhat, so for understanding, what's the parallel in rpm (or deb)? is there a documented concept for this, because I can't seem to find anything other than post releases. Marcus
www.rpm.org/max-rpm/s1-rpm-inside-tags.html " The following tags are used by RPM to produce the package's final name. Since the name is always in the format: <name>-<version>-<release> it's only natural that the three tags are known as name, version, and release. " On Fri, May 2, 2014 at 3:01 PM, Marcus Smith <qwcode@gmail.com> wrote:
PEP440 has the "local version" idea to distinguish locally patched projects from upstream versions. http://legacy.python.org/dev/peps/pep-0440/#local-version-identifiers
e.g. Django-1.6.4-1 for a locally patched Django-1.6.4 to place on a local index.
Although it doesn't relate directly to this list, I know Nick (the PEP440 author) works with Redhat, so for understanding, what's the parallel in rpm (or deb)? is there a documented concept for this, because I can't seem to find anything other than post releases.
Marcus
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I’m pretty sure all the distros have some equivalent to it, often times with similar syntax. On May 2, 2014, at 3:44 PM, Marcus Smith <qwcode@gmail.com> wrote:
not clear at all how you're answering the question.
The following tags are used by RPM to produce the package's final name. Since the name is always in the format:
<name>-<version>-<release>
it's only natural that the three tags are known as name, version, and release. " _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Fri, May 2, 2014 at 1:15 PM, Donald Stufft <donald@stufft.io> wrote:
I’m pretty sure all the distros have some equivalent to it, often times with similar syntax.
e.g. look here https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning yes there's a parallel to our post-releases, namely "Post-Releases", but I don't see a concept for local patches of rpms. to be clear to Daniel, I'm not asking how to package a "local version" of a python package. that's straightforward (I think) because that's all contained in the "version" segment of the rpm. e.g., I recently created an rpm for virtualenv-1.11.4, because centos6 didn't have it yet: python-virtualenv-1.11.4-1.el6.noarch.rpm what's the proper way to "localize" this to not conflict later when 1.11.4 is packaged? again, sorry for the off-topic post, but I was *hoping* Nick (or someone) would have the concept handy from the OS packaging world.
On 2 May 2014 13:33, "Marcus Smith" <qwcode@gmail.com> wrote:
On Fri, May 2, 2014 at 1:15 PM, Donald Stufft <donald@stufft.io> wrote:
I’m pretty sure all the distros have some equivalent to it, often times
with similar syntax.
e.g. look here
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning
yes there's a parallel to our post-releases, namely "Post-Releases", but I don't see a concept for local patches of rpms.
to be clear to Daniel, I'm not asking how to package a "local version" of a python package. that's straightforward (I think) because that's all contained in the "version" segment of the rpm.
e.g., I recently created an rpm for virtualenv-1.11.4, because centos6 didn't have it yet: python-virtualenv-1.11.4-1.el6.noarch.rpm what's the proper way to "localize" this to not conflict later when 1.11.4 is packaged?
Make the release portion of your custom RPM start with a 0 so it sorts before the actual release. For example: python-virtualenv-1.11.4-0.1.el6.noarch.rpm (you can add additional identifying stuff as well - for Beaker QA builds, we use "0.git.<hash>.el6" as the release field)
again, sorry for the off-topic post, but I was *hoping* Nick (or someone) would have the concept handy from the OS packaging world.
From an upstream perspective, it's mostly just extra information for debugging purposes - the version comparison operations deliberately ignore
Yep, the distro release field is basically where "local version" comes from. It's there so distros (and other redistributors) can eventually start advertising the existence of distro specific patches in their Python metadata without confusing version constraints on dependencies. the "local version" field. Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
"Local version" in the PEP corresponds to the distro "release" concept
roger, but the question is what's the "local version scheme" in rpm/deb world for a distro "release"? "version" comes from the packaged project (which is upstream to the distro) "release" comes from the distro.(which is upstream to "me") so how do I properly tack on a "local version"? Barry's example from debian/ubuntu was: <release><tag><N> (e.g. "2ubuntu3", where "2" was debian's release) Your answer was <release>.<N> (e.g. "0.1") My concern with your answer is that looks like an upstream post-release? In general, it sounds like there is no formal concept in rpm/deb for this, so people just cook their own approach.
On 2 May 2014 13:15, "Marcus Smith" <qwcode@gmail.com> wrote:
not clear at all how you're answering the question.
"Local version" in the PEP corresponds to the distro "release" concept. We can't use that specific terminology because we already use "release" to mean something else. Cheers, Nick.
The following tags are used by RPM to produce the package's final name. Since the name is always in the format:
<name>-<version>-<release>
it's only natural that the three tags are known as name, version, and
release.
"
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 3 May 2014 16:44, "Marcus Smith" <qwcode@gmail.com> wrote:
<name>-<version>-<release>
I see the confusion now. I'm asking if there is a formal convention for "localizing" the release value?
That's up to the distro, and is likely to be based on conventions and package manager features rather than exact naming rules. In the case of RPM, it's "use a leading 0." (and optionally a custom suffix) if you building an RPM early and want the official RPM to replace yours once it is available, use a custom suffix if you want the *next* official update to replace yours, and the version pinning/package exclusion features of the distro package manager if you don't want it automatically updated at all.
and you're answering with "'releases' are to 'versions' in rpm, like 'local versions' are to 'public versions' in PEP440"
Right, because there's no "one true way" to manage it - it depends on the integration environment. In the custom RPM case, the PEP 440 "local version" and the leading numeric portion of the RPM "release" should *still* be the same (just as they should be for distro packages), but you'd choose a different local version/RPM release value based on how you wanted the ordering to be handled relative to other RPMs - it wouldn't be governed by any Python level policy. However, I'm wondering if the rules for local version identifiers should be relaxed to allow arbitrary alphanumeric subcomponents in the integrator suffix. The RPM release field allows things like "0.git.15.abcdefabc" - I'd really like to be able to publish that as the "local version" in the Python metadata.
From Barry's description of the "2ubuntu3" style suffixes used when Ubuntu includes patches Debian doesn't, a more permissive integrator suffix would also help in the Debian/Ubuntu ecosystem.
Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In the custom RPM case, the PEP 440 "local version" and the leading numeric portion of the RPM "release" should *still* be the same (just as they should be for distro packages), but you'd choose a different local version/RPM release value based on how you wanted the ordering to be handled relative to other RPMs - it wouldn't be governed by any Python level policy.
However, I'm wondering if the rules for local version identifiers should be relaxed to allow arbitrary alphanumeric subcomponents in the integrator suffix. The RPM release field allows things like "0.git.15.abcdefabc" - I'd really like to be able to publish that as the "local version" in the Python metadata.
From Barry's description of the "2ubuntu3" style suffixes used when Ubuntu includes patches Debian doesn't, a more permissive integrator suffix would also help in the Debian/Ubuntu ecosystem.
yea, if you recall, at one point that idea was ".localN", then it switched to "-N" the switch seemed to be in this post where Donald references a discussion with Noah. https://bitbucket.org/pypa/pypi-metadata-formats/issue/1/add-integrator-suff... wondering if alphanumerics were intentionally excluded, or just not considered given the context at the time was about ".localN" vs "-N"
In the custom RPM case, the PEP 440 "local version" and the leading
numeric portion of the RPM "release" should *still* be the same (just as
However, I'm wondering if the rules for local version identifiers should
be relaxed to allow arbitrary alphanumeric subcomponents in the integrator suffix. The RPM release field allows things like "0.git.15.abcdefabc" - I'd really like to be able to publish that as the "local version" in the Python
On 6 May 2014 08:48, "Marcus Smith" <qwcode@gmail.com> wrote: they should be for distro packages), but you'd choose a different local version/RPM release value based on how you wanted the ordering to be handled relative to other RPMs - it wouldn't be governed by any Python level policy. metadata.
From Barry's description of the "2ubuntu3" style suffixes used when
Ubuntu includes patches Debian doesn't, a more permissive integrator suffix would also help in the Debian/Ubuntu ecosystem.
yea, if you recall, at one point that idea was ".localN", then it switched to "-N" the switch seemed to be in this post where Donald references a discussion with Noah.
https://bitbucket.org/pypa/pypi-metadata-formats/issue/1/add-integrator-suff...
wondering if alphanumerics were intentionally excluded, or just not
considered given the context at the time was about ".localN" vs "-N" I don't recall making a conscious decision - I think I just copied the existing restrictions for "Version" without accounting for the fact the version constraints are all defined to ignore the local version information anyway. Cheers, Nick.
On May 02, 2014, at 12:01 PM, Marcus Smith wrote:
PEP440 has the "local version" idea to distinguish locally patched projects from upstream versions. http://legacy.python.org/dev/peps/pep-0440/#local-version-identifiers
e.g. Django-1.6.4-1 for a locally patched Django-1.6.4 to place on a local index.
Although it doesn't relate directly to this list, I know Nick (the PEP440 author) works with Redhat, so for understanding, what's the parallel in rpm (or deb)? is there a documented concept for this, because I can't seem to find anything other than post releases.
Debian (and thus of course also Ubuntu) packages usually start with the upstream version number, and add additional qualifiers on the end. So for example, upstream Django 1.6.1 might be packaged in Debian as 1.6.1-2 (meaning, the 2nd Debian-specific revision of upstream's 1.6.1). When a Debian developer modifies the package, they'll typically bump the number after the dash. Ideally Ubuntu would just inherit the Debian version, but when we need to make additional deltas to the Debian packages, we'll have a more specific qualifier, such as 1.6.1-2ubuntu3. That tells you that the package is upstream 1.6.1, with Ubuntu rev 3 over Debian rev 2. A package that's only in Ubuntu might look like 1.6.1-0ubuntu3 (the 0 meaning there's no Debian equivalent yet of 1.6.1). There are plenty of variations, including many that don't strictly follow this scheme, e.g. if a version is packaged from a vcs branch. But this should give you a taste of the most common version numbers you'll see on Debian and Ubuntu. Cheers, -Barry
participants (5)
-
Barry Warsaw -
Daniel Holth -
Donald Stufft -
Marcus Smith -
Nick Coghlan