Fedora Project launches Pre-Extras

Dag Wieers dag at wieers.com
Sun Dec 19 01:07:38 UTC 2004


On Sat, 18 Dec 2004, seth vidal wrote:

> > > 
> > > nope. Just means a user thinks something is from somewhere by looking at
> > > the filename, not looking at the content or the signature.
> > 
> > Correct, at the same time people can see when a repository is misleading 
> > people. It's functional as an identifier to select a package or to see 
> > what the origin is in Yum/Apt output.
> 
> > Again, from a strict principal point of view you're correct.
> 
> I've said it before and i'll say it again:
> 
> EPOCH, VERSION AND RELEASE ARE USED IN VERSION COMPARISON!

I never denied that. Repotags don't play a relevant role in the 
comparison. Not in the cases where the absense of the repotag would make a 
real difference.


> We shouldn't have non-version-comparison data used to compare versions.

Why not ? It does not harm.


> It's a pollution of the space and a confusion of what they do.

Read the list of advantages. Don't ignore based on strict principals. 
fedora.us has been using the name-tag for version information (like kernel 
versions) too. Are you against that too ? (I was)


> If you cannot see how they confuse what is a version issue then you're
> self-deluding.

They don't confuse and there's no good alternative and I want/need this 
functionality.


> > Why is that necessary ? Why do you consider the current release field less 
> > useful ? Having a disttag and vendortag in the release tag (and 
> > filename) is _very_ useful. Maybe not to you, but to many others (both in 
> > bugreports or just as an identifier to select packages).
> 
> I don't care about the filename. The filename is nothing - I care about
> the garbage getting in fields that I need to use to do version
> comparison.

If your implementation is good, it should not matter.


> have .dag. or .fdr. or .fr. since it does not make a claim about the
> version of the software, only a statement about which repo it came from
> (and not an authoritative statement at that) is just pollution.

It's not exactly pollution. It's irrelevant to the version comparison and 
has a whole list of advantages on its own.

   1.  To make unfit for or harmful to living things, especially by the 
       addition of waste matter.
   2. To make less suitable for an activity, especially by the 
      introduction of unwanted factors.
   3. To render impure or morally harmful; corrupt.
   4. To make ceremonially impure; profane:

The only unwanted factor may be an extra cpu-cycle that I'm sure people 
happily accept.


> > Sorry, Seth, I disagree. I see 'useful' in a less strict sense. I consider 
> > other uses than only the version comparison. And it does not interfere 
> > with that and there's no other harm.
> > 
> > But then again, if you're talking as the authority repository and don't 
> > see a use in 3rd party repositories, there's no need for a repotag. But 
> > for a complete other reason.
> 
> I see useful in the specific sense of being one of the people who
> maintains and works on dependency solvers.

Well, RPM does it correctly. There's no reason why Yum would do it 
differently.

I see useful in the broad way of the many thousands of people _using_ the 
packages. We're making software for people, other than developers or 
dependency solvers.


> >From a cleanliness of programming it'd be a lot nicer to match repo
> based on gpg signature than based on some arbitrarily-placed string in
> the release tag.

I agree, but we can't add the gpg signature to the filename or the 
relevant part that is shown by Yum/Apt/up2date. So it does not serve the 
purpose we use the disttag and the repotag for.

Please read the list of advantage again and don't ignore the uses of the 
repotag. The GPG signature is useful, but not a replacement for the 
repotag.


> If you want to make the tools better you have to store the data in sane
> places and don't pollute other fields with it.

Sigh. Seth, I can't do that and I'm certain Red Hat will not consider it.
It would break everything, while there currently are no other 
disadvantages than one good RPM-based-tool developer with a few 
principals.

If you have a better alternative I gladly accept, but not if it does not 
conform the current list of advantages.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]




More information about the fedora-test-list mailing list