Warren's Package Naming Proposal - Revision 1

[Warren Togami]

Mike A. Harris wrote:
> 
>>vepoch
>>This is our term for "version specific epoch", used in all packages as a 
>>simple means of ensuring upgrades by simple incrementing the leading 
>>number within the release tag.  vepoch is otherwise known as "release 
>>number" or "patchlevel".  Read C-2 for more information.
> 
> 
> The "Epoch" tag is already quite confusing to many/most beginner 
> and intermediate packagers, perhaps even some advanced packagers. 
> It's often used when not needed, and with a small amount of 
> forethought when packaging things can be completely avoided in 
> many if not all cases where Epoch ends up being used nowadays by 
> someone.
> 
> I think your "vepoch" tag potentially adds confusion between what 
> Epoch is and what vepoch is.  I unfortunately don't have a better 
> name to offer other than perhaps "versionserial" to indicate a 
> monotonically increasing serial number tied to a version.
> 
> Just a personal opinion that this might confuse people, and if a 
> better name can be chosen that is short enough and clear, it 
> might be better.

Hmmm, I am in agreement.  While we fedora.us people had no problem with 
vepoch for many months, I can see where it is confusing.  I designed the 
name to be "Kind of like epoch, vepoch trumps all, but less."

Perhaps "patchlevel" is a better word.

>>B. Version
>>==========
>>If the version is only numbers, then these numbers can be put into the
>>"version" field of the RPM .spec unchanged.  If the version contains
>>non-numeric characters, this creates several problems for RPM version
>>comparison and a broken upgrade path.
>>
>>Example:
>>foobar-1.2.3beta1.tar.gz
>>foobar-1.2.3.tar.gz
>>
>>While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM
>>version comparison thinks the former is newer.
>>
>>Example:
>>foobar-1.0a
>>foobar-1.0b
>>
>>The "1.0b" version is higher than "1.0a", but all versions of RPM prior
>>to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever
>>package is first in the comparison "wins", thus this becomes a  two way
>>upgrade problem.  This a < b comparison works properly only in RH9 and 
>>higher.
>>
>>For simplicity, Fedora treats both pre-release and post-release
>>non-numeric version cases the same, making the version purely numeric
>>and moving the alphabetic part to the release tag.  Take the numeric
>>portion of the source version and make that the package version tag.
>>
>>Read C-3 for more details.
> 
> 
> I strongly agree with this approach.  Probably because I stole it 
> from bero, and I think you picked it up from me or from bero 
> also.  ;o)  It works very well IMHO.  It's also very useful with 
> CVS based releases where you can embed the CVS date into the 
> release field instead of the version field, thus avoiding having 
> to use Epoch later on to override the large integer release 
> number from a CVS date.

Yes, when I originally designed this method I was pointing at bero's 
packages as justification.  "See!  Look, Red Hat did it!"

Conspiracy theory: Was he canned because of persecution from aberrant 
packaging? =)
Ok... bad joke.

>>C-3. Non-Numeric Version to Release
>>-----------------------------------
>>As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric
>>versioned packages can be problematic so they must be treated with care. 
>> These are cases where the upstream version has letters rather than
>>simple numbers in their version.  Often they have tags like alpha, beta,
>>rc, or letters like a and b denoting that it is a version before or
>>after the number.  Read section B to understand why we cannot simply put
>>these letters into the version tag.
>>
>>Release Tag for Pre-Release Packages:
>>     0.%{X}.%{alphatag}
>>Release Tag for Non-Numeric Post-Release Packages:
>>     %{X}.%{alphatag}
>>
>>Where %{X} is the vepoch increment, and %{alphatag} is the string that
>>came from the version.
>>
>>Example (pre-release):
>>     mozilla-1.4a.tar.gz   from usptream is lower than
>>     mozilla-1.4.tar.gz    the later "final" version thus
>>     mozilla-1.4-0.1.a     Fedora package name
>>
>>Example (pre-release):
>>     alsa-lib-0.9.2beta1.tar.gz  becomes
>>     alsa-lib-0.9.2-0.1.beta1
>>
>>Example (post-release):
>>     gkrellm-2.1.7.tar.gz
>>     gkrellm-2.1.7a.tar.gz       Quick bugfix release after 2.1.7
>>     gkrellm-2.1.7-1.a
> 
> 
> For gkrellm is this necessary?  rpm considers 2.1.7a newer than 
> 2.1.7 already unless something has changed.  Another package of 
> this nature is UW imap.  It is generally released with an integer 
> based version number of the year of it's release, possibly 
> followed by a single letter indicating a revision within that 
> year.  ie:  imap-2000 imap-2000a imap-2000b
> 
> In rpm's normal operation these packages are naturally treated as 
> the older package on the left, with the newer ones proceeding to 
> the right.
> 
> My personal preference would be to just let rpm assume that as it
> should work.  I've never gotten bug reports of it not working
> anyway.  Moving things from the version to the release field
> unnecessarily just complicates packaging when there's no real
> benefit IMHO.  For the pre-release cases above it makes sense as
> it's being done in order to override rpm's default behaviour,
> which would be to treat what is a final release as older than a
> prerelease.
> 
> I believe treating both pre-release and post-release in the same
> manner just for consistency with both types of lettered versioned
> packages is just cosmetic consistency, but doesn't provide any
> functional or technical benefit.  In other words, sticking with
> the upstream version in the version field is IMHO best unless
> there is a technical benefit of doing so, such as avoiding having
> to later use Epoch to override a prerelease build.
> 
> Are there cases where rpm would consider imap-2000a as older than 
> imap-2000?
> 
> jbj?
>

Err... you are completely right about it not being necessary in the 
post-release case.  I am not sure why our fedora.us policy retained that 
even though it was unnecessary for all these months.  The way I 
understand the older version of rpm broken rpmvercmp behavior, this 
wouldn't be a problem with those versions too.


>>C-4. Dist tag
>>-------------
>>In cases where the same SRPM and patchlevel is used between two or more
>>distributions supported by Fedora, a dist tag is appended to the end of
>>the release tag defined in C-2 and C-3.  The dist tags with the
>>following examples appear to be only cosmetic, however the a different
>>E-V-R is needed between distributions to ensure dist upgrading works
>>fully in all corner cases.
>>
>>Dist Tag for Normal Packages:
>>     %{X}.%{disttag}
>>Where %{X} is the vepoch and %{disttag} is a distribution tag from this 
>>table:
>>
>>0.7.3 Red Hat Linux 7.3
>>0.8   Red Hat Linux 8
>>0.9   Red Hat Linux 9
>>1     Fedora Core 1
>>1.93  Fedora Core 1.93 beta
>>1.94  Fedora Core 1.94 beta
>>2     Fedora Core 2 beta
>>
>>Example:
>>     foobar-1.2.3-1_0.7.3.i386.rpm
>>     foobar-1.2.3-1_0.8.i386.rpm
>>     foobar-1.2.3-1_0.9.i386.rpm
>>     foobar-1.2.3-1_1.94.i386.rpm
>>     foobar-1.2.3-1_2.i386.rpm
>>
>>Upgrade Path Example (FC1 only shown):
>>     foobar-1.2.3-1_1.i386.rpm
>>     foobar-1.2.3-2_1.i386.rpm
>>     foobar-1.2.3-3_1.i386.rpm
> 
> 
> Ick.  Underscores in version/release are hideous IMHO.  I'd use 
> "." instead of "_".  Your comment at the top of this section 
> indicates a ".", so perhaps you just made a typo, and sequence of 
> cut and paste errors?  ;o)

Oops.  Yeah, fedora.us original plan was ".", however some here on 
fedora-devel-list argued toward "_" as a more clear separator between 
the patchlevel and disttag because it can be confusing with so many "."

I personally actually prefer the "." separator, but I really don't care 
which is chosen.

Warren