[elrepo-devel] Naming guidelines

[Phil Perry]

Nikolay Ulyanitsky wrote:
> I have not found any ELRepo naming guidelines.
> 
> I think we must use Fedora Naming Guidelines
> (http://fedoraproject.org/wiki/Packaging/NamingGuidelines)
> as template of ELRepo naming guidelines.
> 
> Example of Naming guidelines:
>   * %{X} - original module version
>   * %{Y} - incremented release number
>   * %{VCSTAG} - version control system tag (20050515cvs, svn12345,
> git5aef11739b, etc).
>   * %{DIST} - macro, for example .el5.repo
> 
> I. Packages with backported modules:
>     %{NAME}-0.0-%{Y}%{DIST}
> 
>     Many kernel modules have a version < 1.0.0, for example: 0.0.3,
> 0.12, 0.99t-ac, etc.
>     We should never change the version from 0.0.
> 
>     foo-0.0-1.el5.repo
>     foo-0.0-2.el5.repo
>     foo-0.0-3.el5.repo
>     ...
> 

We had some discussions regarding package naming guidelines, but I/we 
haven't got around to formally writing them up yet (lets put them on the 
Wiki together with packaging guidelines etc). Unfortunately, those 
discussions took place before we had the mailing lists in place, so they 
weren't public, but in our own roundabout way we arrived pretty much at 
the same place described above (which I guess is a good thing).

Generally,

kmod-foo-0.0-1.el5.elrepo

where no module version information is otherwise available.

I take your point about never incrementing the version number (even the 
minor version number).

Where module version information is available, we use it and then 
increment the release as appropriate. An example of this would be my 
(broken) kmod-sis190-1.3-1.el5.elrepo package using backported kernel 
code labelled as version 1.3 in the code, or for kmod-alsa-1.0.20-1 
based on ALSA 1.0.20.

An example of code snapshot naming can be seen in the current V4L package:

kmod-video4linux-0.0-5.20090615.el5.elrepo

We did make some mistakes early on by versioning some packages starting 
at 1.0-1 and incrementing through 1.1-1 etc (eg, coretemp, it87). After 
realising our mistakes we decided not to go back and correct something 
that's not currently causing a problem as the fix (introducing an epoch) 
might be considered worse than the mistake.

We also discussed at length whether the package version-release should 
contain any information to indicate which kernel the package was built 
against (eg, a package built against the 5.3 release kernel-2.6.18-128 
might be named foo-0.0-1.el5.3.elrepo or foo-0.0-1.128.el5.elrepo) but 
we decided against this as it was felt this information could be 
misinterpreted and/or cause confusion.