Clarification/ammendment to the "non-numeric characters are permitted in the Version: field" clause

[Fernando Nasser]

Hi, the Naming Guidelines has the following provision in

http://fedoraproject.org/wiki/Packaging/NamingGuidelines?highlight=%28Pac...

"Post-release packages: Packages released after a "final" version. This 
usually is due to a quick bugfix release, such as openssl-0.9.6b  or 
gkrellm-2.1.7a. In this case, the non-numeric characters are permitted 
in the Version: field."

Actually there is another case where the upstream version has 
non-numeric characters: when they have dual-license and name each of 
their releases with a letter to discriminate under which license that 
tar ball is.  This is not described above.

Furthermore, there may be additional complications (see below).

The letters vary, but here is an example:

The Saxon library has two tar balls for their 8.8 release

http://prdownloads.sourceforge.net/saxon/saxonb8-8j.zip

where B is the Open Source licensed one (and I believe and "A" marks the 
non-free one).

If the version gets the letters in this order we would have:

saxon-B8.7-1jpp.src.rpm

That broke my scripts that separate the VR from the package name 
(perhaps my regexp is not good enough).

What is the better way to handle this:

1) Do not mention the "B" at all, as we only release Open Source 
licensed software anyway.  But what if the two licenses are GPL and ASL 
for instance? or GPL and BSD...

2) Add the letter to the name of the package (like saxon-b) and add a 
virtual provides for 'saxon'  (Argh! I find it ugly)

3) Leave it in the version field, but not as the first character.  But 
in that case, moving it to the end may get it mixed up with the case 
described in the guidelines: "Packages released after a "final" version. 
This usually is due to a quick bugfix release, such as openssl-0.9.6b 
or gkrellm-2.1.7a"

4) Leave it in the version field in the position where it was upstream 
(and Fernando has to improve his regexps, *if* he is the only one 
affected and not mock for instance).


Any ideas, suggestions, comments?


Regards to all,
Fernando

[Tom Callaway]

On Thu, 2007-02-08 at 14:37 -0500, Fernando Nasser wrote:

>  What is the better way to handle this:
>  
>  1) Do not mention the "B" at all, as we only release Open Source 
>  licensed software anyway.  But what if the two licenses are GPL and ASL 
>  for instance? or GPL and BSD... 
I vote for this. I think it is rather unlikely that we'd have a GPL vs
ASL or GPL vs BSD licensed software component.

~spot

[Jason L Tibbitts III]

> >>>> "TC" == Tom 'spot' Callaway
> <tcallawa(a)redhat.com&gt; writes: 
TC> I vote for this. I think it is rather unlikely that we'd have a
TC> GPL vs ASL or GPL vs BSD licensed software component.

And even if we did, the license tag would indicate the license of the
package well enough.

 - J<

[Fernando Nasser]

Jason L Tibbitts III wrote:
> >>>>> "TC" == Tom 'spot' Callaway
> <tcallawa(a)redhat.com&gt; writes:
>  
>  TC> I vote for this. I think it is rather unlikely that we'd have a
>  TC> GPL vs ASL or GPL vs BSD licensed software component.
>   
Such beasts do exist (Apache forced some folks to dual-license with the 
ASL their GPL'ed code in order to do collaborative development).
But I agree it is unlikely (BTW, that story did not have a very happy 
ending).


>  And even if we did, the license tag would indicate the license of
> the
>  package well enough.
>   
Right.

Ad if we ever have to release more than one, we will need different 
package names anyway, like apache-joram and objectweb-joran, each with 
its proper License:.


So I vote for (1) as well:  +1