On May 18, 2004, Axel Thimm <Axel.Thimm@xxxxxxxxxx> 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@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
