Re: [Distutils] PEP440 Local versions idea in rpm/deb?
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-suffix-to-pep-440#comment-5773507 wondering if alphanumerics were intentionally excluded, or just not considered given the context at the time was about .localN vs -N ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
On 6 May 2014 08:48, Marcus Smith qwc...@gmail.com wrote: 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-suffix-to-pep-440#comment-5773507 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. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
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: releasetagN (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. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
name-version-release I see the confusion now. I'm asking if there is a formal convention for localizing the release value? and you're answering with 'releases' are to 'versions' in rpm, like 'local versions' are to 'public versions' in PEP440 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
On 3 May 2014 16:44, Marcus Smith qwc...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
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 qwc...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
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
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
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 qwc...@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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
On Fri, May 2, 2014 at 1:15 PM, Donald Stufft don...@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. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
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 signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
On 2 May 2014 13:15, Marcus Smith qwc...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 Local versions idea in rpm/deb?
On 2 May 2014 13:33, Marcus Smith qwc...@gmail.com wrote: On Fri, May 2, 2014 at 1:15 PM, Donald Stufft don...@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. 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. From an upstream perspective, it's mostly just extra information for debugging purposes - the version comparison operations deliberately ignore the local version field. Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
