On Mon, 18 Sep 2000, Joey Hess wrote: > Actually, I would prefer not to use numbers in the actual Packages file. We > should use a textual representation; implementations can convert to > numbers as needed. Contrast with the Priority field. Of course this > messes with your idea of continually incrementing numbers.
Well, that is completely unworkable :| If each version has a unique priority realitive to the previous version then we no longer have the information. Consider my example: Ver=1.0 Urgency=0 Urgency=low Ver=1.1 Urgency=100 Urgency=high Ver=1.2 Urgency=200 Urgency=high Ver=1.3 Urgency=300 Urgency=high Ver=1.4 Urgency=300 Urgency=low Now lets say the user has 1.0 installed and v1.4 available. They have no way to know that there has been *3* security fixes! Without a way to maintain a history across every version it is impossible to know what has happened in the versions you can no longer see [1.1 to 1.3 in this example]. That reduces the usability of the feature to about the level of a cheap hack.. > And the changelog probably is the right place as far as the source > package goes. It's annoying to force people to edit the control file It must go in the control file or dpkg will not put it in the status file. If it is not in the status file then the idea cannot work since you cannot compute a new urgency from the current basis. Urgency in the changelog is explicitly relative to the last release, we need an absolute urgency so we can perform meaningful comparisions across time. The trick is that we encode the relative urgency from the change log into the difference between numbers. You could probably compute the urgency value from the change log just by summing all the urgencies of each release. Taking care to never truncate the changelog. Jason
