[packagers] RPMForge disttag format?

[Tom G. Christensen]

Dag Wieers wrote:
> On Wed, 15 Nov 2006, Tom G. Christensen wrote:
> 
>> What I'm seeing is that rpms from Dag and Matthias are nolonger using the
>> format with a numeric prefix as described in naming-policy.txt.
>> Dries on the other hand seems to be using the old format even with fc6.
>>
>> Since I build a number of local packages and have implemented the old RPMForge
>> format in my .rpmmacros I'd like to know if there's some consensus on the
>> future direction of the RPMForge disttag format?
> 
> Yes, the direction we took was that we increased the Release tag of all 
> packages from X to X.2 and dropped the numeric prefix. This allowed us to 
> migrate away from the numeric prefic without any issues.
>
Aha!

I think I get it now, ie. 2.el4 is nolonger the disttag, only .el4 is
and 2 is now part of the release number.

> New version updates to packages will remove the X.2 and start from 1 
> again. New release updates will move from X to X+1 (so that X.2 < X+1) :)
> 
As long as only the specfile is tweaked and the software version remains
the same the release number is X.2, yes?

> It has not been discussed in public since it idn't directly affect anyone 
> other than us, at least that's what we thought. I guiess we were wrong :)
> 
Indeed :)

I just add %{?dist} to the Release field and I get a package
disttagged RPMForge style :)

Since I support all 3 current RHEL releases inhouse I needed a disttag
format for my custom packages and I went with RPMForge.
The alternative at the time was Fedora(.us), but RPMForge seemed more 
mature and I was more comfortable with the goals of the project.

I always hoped that a recipe for setting up an RPMForge compatible 
buildsystem would become available, unfortunately that never happened.
I would have loved such a howto along with a macros.rpmforge file that 
actually had all the macros needed.
Now I had to write my own macros instead and have setup a buildsystem 
based on mock.

> So if you still see X.2.fc6 packages instead of X.fc6 that just means 
> there has not been a version update of that package since we implemented 
> this new scheme. And for that reason the X.2.fc6 is still important to 
> drag around (so that X.2.fc5 < X.2.fc6). For any version update the 
> numeric release is gone (even for Dries).
> 
I see that now. The packages I had looked at where ofcourse all of the
non-version updated variety hence my faulty conclusion.

> Let me know if you still have any concerns about this.
>
No technical concerns.

What concerns me is that the RPMForge effort has been so easily 
dismissed by other similar projects and the careless disregard those 
other repositories show toward maintaining compatibility with RPMForge.
The future of RPMForge concerns me as the project from my POV has 
stagnated :(

-tgc