Fedora Project launches Pre-Extras

[Dag Wieers]

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 at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]