On Fri, 2004-12-17 at 13:13, Michael Schwendt wrote: > It doesn't add any value. When you receive a bug report about > foo-2.0-1.i386.rpm (assuming it's your package) and the reporter > referred to foo-2.0-1 specifically (because the bugzilla form asks him > to do so), have you ever verified whether it was really your package > and not an arbitrary one found at rpmseek.com? True, but don't forget if the release field consisted of only an integer it gives you no useful information because the release "number" only has meaning within a distribution. Suppose you know a patch was applied in release 4 of the rpm in FC3 that fixes the bug reported. Some other distro can and probably did release that rpm with its release set to 4 with an entirely different patch set and/or build configuration. One always have to be able to refer back to the spec file for any meaningful information about the package. Spec files are distribution specific. Since the spec file controls virtually everything about a package and the spec file is a property of the distribution the act of divorcing the spec file "name space" from the rpm name leaves a very large and real information gap. This is not an academic issue, those of us supporting packages built for RHEL* and FC* deal with this on a daily basis. This is relatively constrained problem space compared with the universe of possible distributions. Mapping an rpm name to the specific spec file that produced the rpm should be a goal. Encoding the spec file "name space" in the release field is one possible solution. I'm not suggesting its the ideal solution, maybe far from it, but at the end of the day one has to reliably map rpm names to spec files. Whatever gets us to that goal works for me :-) -- John Dennis <jdennis@xxxxxxxxxx>