Defining some official package naming standards

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Defining some official package naming standards

Max O Bowsher
The recent thread about remake suggests it would be a good idea to
define some actual official package naming rules: exactly what things
are considered valid for the name, version, and release fields in a package.

I propose:

A package NVR identifier is name-version-release - three fields
separated by '-' characters.

The release field MUST NOT contain a '-' character.

The version field MUST begin with a digit. Well-behaved parsers should
allow it to contain '-' characters, but package creators should try to
avoid this because it can lead to NVRs that look confusing.

The name field may contain '-' characters, EXCEPT that it MUST NOT
contain a '-' character immediately followed by a digit.


Max.


signature.asc (195 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Defining some official package naming standards

Corinna Vinschen-2
On Aug 12 23:13, Max Bowsher wrote:

> The recent thread about remake suggests it would be a good idea to
> define some actual official package naming rules: exactly what things
> are considered valid for the name, version, and release fields in a package.
>
> I propose:
>
> A package NVR identifier is name-version-release - three fields
> separated by '-' characters.
>
> The release field MUST NOT contain a '-' character.
>
> The version field MUST begin with a digit. Well-behaved parsers should
> allow it to contain '-' characters, but package creators should try to
> avoid this because it can lead to NVRs that look confusing.
>
> The name field may contain '-' characters, EXCEPT that it MUST NOT
> contain a '-' character immediately followed by a digit.

Weird, but I always thought that the above is already state of the art.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Reply | Threaded
Open this post in threaded view
|

Re: Defining some official package naming standards

Max O Bowsher
Corinna Vinschen wrote:

> On Aug 12 23:13, Max Bowsher wrote:
>> The recent thread about remake suggests it would be a good idea to
>> define some actual official package naming rules: exactly what things
>> are considered valid for the name, version, and release fields in a package.
>>
>> I propose:
>>
>> A package NVR identifier is name-version-release - three fields
>> separated by '-' characters.
>>
>> The release field MUST NOT contain a '-' character.
>>
>> The version field MUST begin with a digit. Well-behaved parsers should
>> allow it to contain '-' characters, but package creators should try to
>> avoid this because it can lead to NVRs that look confusing.
>>
>> The name field may contain '-' characters, EXCEPT that it MUST NOT
>> contain a '-' character immediately followed by a digit.
>
> Weird, but I always thought that the above is already state of the art.
The above is a set of rules distilled from current practice, but I don't
think we've actually defined and documented this before.

Max.


signature.asc (195 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Defining some official package naming standards

Dave Korn
On 14 August 2006 09:58, Max Bowsher wrote:

> Corinna Vinschen wrote:
>> On Aug 12 23:13, Max Bowsher wrote:
>>> The recent thread about remake suggests it would be a good idea to
>>> define some actual official package naming rules: exactly what things
>>> are considered valid for the name, version, and release fields in a
>>> package.
>>>
>>> I propose:
>>>
>>> A package NVR identifier is name-version-release - three fields
>>> separated by '-' characters.
>>>
>>> The release field MUST NOT contain a '-' character.
>>>
>>> The version field MUST begin with a digit. Well-behaved parsers should
>>> allow it to contain '-' characters, but package creators should try to
>>> avoid this because it can lead to NVRs that look confusing.
>>>
>>> The name field may contain '-' characters, EXCEPT that it MUST NOT
>>> contain a '-' character immediately followed by a digit.
>>
>> Weird, but I always thought that the above is already state of the art.
>
> The above is a set of rules distilled from current practice, but I don't
> think we've actually defined and documented this before.
>
> Max.

  Mustn't the release field begin with a digit too?

  So, as this stands, VER='3.80+dbg-0.61' would be valid?  I don't suppose it
would play well with upset's automatic prev/curr detection.

    cheers,
      DaveK
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

Re: Defining some official package naming standards

Max O Bowsher
Dave Korn wrote:

> On 14 August 2006 09:58, Max Bowsher wrote:
>
>> Corinna Vinschen wrote:
>>> On Aug 12 23:13, Max Bowsher wrote:
>>>> The recent thread about remake suggests it would be a good idea to
>>>> define some actual official package naming rules: exactly what things
>>>> are considered valid for the name, version, and release fields in a
>>>> package.
>>>>
>>>> I propose:
>>>>
>>>> A package NVR identifier is name-version-release - three fields
>>>> separated by '-' characters.
>>>>
>>>> The release field MUST NOT contain a '-' character.
>>>>
>>>> The version field MUST begin with a digit. Well-behaved parsers should
>>>> allow it to contain '-' characters, but package creators should try to
>>>> avoid this because it can lead to NVRs that look confusing.
>>>>
>>>> The name field may contain '-' characters, EXCEPT that it MUST NOT
>>>> contain a '-' character immediately followed by a digit.
>>> Weird, but I always thought that the above is already state of the art.
>> The above is a set of rules distilled from current practice, but I don't
>> think we've actually defined and documented this before.
>>
>> Max.
>
>   Mustn't the release field begin with a digit too?
It's not necessary to require that to make NVR strings parseable, since
the release is unambiguously delimited by the final '-' in the string.

Nevertheless, the release field certainly should begin with a digit,
since it would be confusing otherwise.

>   So, as this stands, VER='3.80+dbg-0.61' would be valid?

Technically valid, but falling under the "you should try to avoid this"
clause. Changing the '-' to a '_' is probably the best option.

Max.


signature.asc (195 bytes) Download Attachment