On 6 May 2014 08:48, "Marcus Smith" 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 o
>
>
> 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
> han
On 3 May 2014 16:44, "Marcus Smith" wrote:
>>
>>
>> --
>>
>
> 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.
I
>
>
> --
>
>
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-SI
> "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 upst
On 2 May 2014 13:33, "Marcus Smith" wrote:
>
>
>
> On Fri, May 2, 2014 at 1:15 PM, Donald Stufft 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_Version
On 2 May 2014 13:15, "Marcus Smith" 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 fo
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
>
On Fri, May 2, 2014 at 1:15 PM, Donald Stufft 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
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 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
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:
>
> --
>
> it's only natural that the three tags are known as name, version, and
> release.
> "
>
___
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:
--
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 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
13 matches
Mail list logo
