> We shouldn't have non-version-comparison data used to compare versions. > > It's a pollution of the space and a confusion of what they do. > > If you cannot see how they confuse what is a version issue then you're > self-deluding. > I want to add a bit to this. When setting up a database and determining which fields will store which data you intentionally lay it out so you won't have to search one field to find multiple bits of data. So, for example you would not have a field in a table be: bunch of stuff and then have the specification of the data in 'bunch of stuff' be: fname:username:lname:uid:password:description:usertype:mothersmaidenname You wouldn't do it b/c it's wrong and silly to overload 'bunch of stuff' with data you could easily split out into multiple fields in the table. Now, it's worse when you do it to a field that had an intended use already. so, for example: if you have a field named sortkey. The string in this field determines how the whole row will sort. (look, it's an e-v-r field) You wouldn't store information about the name or location or color or shape of the item in that field b/c that will be an abuse of what the field is for. So by putting information which does not help describe the version- release info of the package (ie: it does not help for comparing the version of one package to another one in any descriptive way) then you're incorrectly overloading the release tag. Ask Gustavo about why he doesn't use the arbitrary string inside the release tag for the priority/repo sorting in smart. B/c it's: 1. not consistent 2. not reliable 3. not authoritative So what do we do about this. I say we do the following: 1. we create a registry for the Vendor Tag inside the spec file and encourage it's use. 2. we encourage gpg signing and the vendor tag registry should match up to a gpg key or a set of gpg keys. 3. we discourage all branding of release tags with useless cruft. 4. we work on using the gpg signature and/or vendor tag as information for collating packages, especially for use in depsolving. B/c you could rely on the gpg sig as an authoritative and reliable source of information about who/where the package was provided by/from. Imo the following should be the use case for the n-e-v-r tags: name: the name of the package/program epoch: override number used sparingly to deal with problematic versioning standard by upstream maintainer (re: mozilla. :) version: the version of the program as released by the upstream maintainer release: versioning information for the release of the package. This includes describing what distro the package is FOR. It should NOT include telling the user where the package is FROM. If you want to know the origin of the package look at who has signed it and who is in the Vendor: field. -sv