On Tue Jul 24, 2001 at 07:22:54PM -0700, Ben Reser wrote:
> > It does seem like a silly idea. If it's the third run at getting an RPM
> > updated, it should be -3mdk, not -1.2mdk. Let's leave the dotted
> > versions to the software and not the package attempts.
>
> I actually believe they were being used to update packages after
> release, so that security updates on say 8.0 didn't end up having the
> same package version as packages in cooker. Apparently that was
> creating much confusing when there were two packages with identical
> versions but different contents.
Exactly. This discussion has been made when we first started using
decimal releases for security updates. The purpose of decimal
releases for updates is so that the package is never higher than what
is in cooker. Cooker should *always* have a higher revision
number... For instance, if a new package comes out that fixes a
security problem, it will be -1mdk in cooker. If I were to follow
"standard" naming conventions, 8.0 would be -2mdk, 7.2 -3mdk, and 7.1
-4mdk... now all of a sudden it looks to rpm that the updates are
newer than cooker. If someone wants to upgrade to something in
cooker, they cannot do so easily because the revision for the update
is higher (in the case of 7.1, as many as three revisions higher).
decimal releases *work*. If they didn't, we wouldn't be using them
and rpm would not be installing them. It is the logic in rpmdrake or
rpminst that has problems and that needs to be corrected, not the
update revision schema.
--
[EMAIL PROTECTED], OpenPGP key available on www.keyserver.net
1024D/FE6F2AFD 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD
- Danen Consulting Services www.danen.net, www.freezer-burn.org
- MandrakeSoft, Inc. Security www.linux-mandrake.com
Current Linux kernel 2.4.3-20mdk-win4lin uptime: 4 days 23 hours 40 minutes.
PGP signature
