On Fri, Aug 10, 2007 at 02:17:44PM -0500, Aaron Griffin wrote:
On 8/10/07, Andreas Radke <a.radke@arcor.de> wrote:
we already have packages with subdecimal versions in both architectures. it's just a question of shell scripting what's the easy way to increase either the pkgrel or add ".1"
it's trivial in both cases. either way, it doesn't seem right to try and optimize a process based on limitations of a language.
Still, I never liked decimal pkgrels. It's the "release" number, or number of times ArchLinux has released or rebuilt the package. It doesn't make sense anymore when you say you released a package 0.3 times.
What was the rationale behind using decimal pkgrels? Because I really have no idea where it started.
That's my fault. We started it with testing and tur releases: 1t1 and 1s1. That way if we were testing revisions that would be released in official as -2, the testing package would be -2t1. Someone figured that users would be confused if packages went from -1 to -3. I didn't think so. After that it was i686 and x86_64. The x86_64 people sometimes had to make changes to PKGBUILDs so that they would build on their machines. When i686 releases -3, x86_64 has to modify it so they release -3.1. That way we'd know that the x86_64 -3.1 was actually just a modification of the i686 package to work with x86_64 instead of being a totally different release -4. There have been a number of cases where people have been confused between ppc, x86_64, and i686 thinking that one release was actually equivalent to another release in a different architecture. We were using this to keep track. What would you think if x86_64 had a -4 version of a package that you have as -3 in i686? Would you think that i686 should update to -4? Or would you check the PKGBUILDs of the two of them to see if one or the other needs an update? Jason