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