Fedora Project launches Pre-Extras

[seth vidal]

> 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