On Sat, 18 Dec 2004, seth vidal wrote: > > 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. It would not give me many of the important advantages in my list. Go read it again, please. To remove one of that list, you could make Yum/rpm show the source/repo on normal operations but that would leave a lot of other advantages out of the picture. -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]