On May 18, 2004, Axel Thimm <Axel.Thimm(a)ATrpms.net> wrote:
> If you use disttags, and you have to patch a package such that
the
> R number goes in between two R numbers that are already out,
Why would you do that? Say you have foo-1.2.3-4 and foo-1.2.3-5 and
the fix comes out, you suggest foo-1.2.3-4.1 and
foo-1.2.3-5.1. Wouldn't that make foo-1.2.3-5, one of the versions
with the security vulnerability overwrite the fixed version from
foo-1.2.3-4.1?
E.g. I have a secury FC3 and use an (outdated) FC4 installation
medium
to upgrade my system. Until I fire up the updater postinstallation my
box is vulnerable.
The assumption is that someone would immediately apply the FC4
updates, fixing the hole.
But think of fixes instead of security patches.
Consider that -5 had a change to make the package buildable on FC4,
that would break on FC3.
Issuing -5.1 (or 6, for that matter) for both FC3 and FC4 implies it's
newer than 5 for FC4. Should someone depend on the patch that made it
buildable for FC4, and say so with a Requires: foo >= 1.2.3-5, issuing
the errata as -5.1.FC3 might incorrectly satisfy the requirement.
As said, this is an old corner stone, and using dotted releases
should
be considered deprecated anyway.
I still think they should be used for the 0.<buildid> case, for *any*
extras that might ever make it to the core (i.e., any extras at all
:-)
--
Alexandre Oliva
http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}