Fedora Project launches Pre-Extras

John Dennis jdennis at redhat.com
Fri Dec 17 18:51:28 UTC 2004


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 at redhat.com>




More information about the fedora-test-list mailing list