On Sat, 18 Dec 2004, seth vidal wrote:
> 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.
As cited previously, it does make a real difference, especially when
it's confusing and misleading to users how it is tagged.
I should still receive my first mail about confusion about the disttag or
repotag.
How confusing and annoying would it be if I decided to make every
package I ever release have a release of 99999.dag.someotherinfo?
The nice thing is that no reasonable person would do that unless they want
to break something on purpose. And if you do and I have your signature
imported in my rpm repository, you can be sure I will not trust you again.
How confusing would it be if I put the kernel-version inside the name-tag
? Yet, fedora.us made that the default policy, and you know why ? Partly
because the Yum developer didn't want a proper solution for this :)
This is the other way around.
I could do that, of course, and you'd get lots of spurious bug
reports.
While your answer might always be: notmybug, get lost, you'd have to
answer them.
You could do that and it may be a hassle, but will it matter ? And will
this ever happen in the real world where it matters ?
It's hypothetical.
> > We shouldn't have non-version-comparison data used to
compare versions.
>
> Why not ? It does not harm.
yes it does,
just like in my example - if you pollute the data you make it harder to
make good decisions based on the data.
It does not pollute and it does no harm. but if you repeat it long enough,
maybe some people will fall for it. I know Jeff did from your first mail
:)
> > 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)
read my explanation of what pollution is.
pollution is when you're adding data that does not describe the release
of the package but only describes where the package is FROM.
Well, I don't have to buy your definition. Pollution is doing harm, this
is harmless and useful.
You're just adding a brand.
No, we're giving people a list of advantages.
https://www.redhat.com/archives/fedora-test-list/2004-December/msg00498.html
Every discussion that ignores that is not worth everybody's time.
so adding a tag like 0.fc1.foo is fine.
Why is 'foo' fine ? And 'rf' not ?
That's helpful in determining the ver/rel of the package.
Adding 'nike' to it or 'coke' isn't helpful.
It is. You have a good hint where it comes from.
it's just advertisement. I understand if you want to be in
marketing,
but I think it's useless in this context. :)
It's not marketing, people care to see where the package comes from.
Please do everyone a favor and read those advantages, I hate to repeat
myself but you keep ignoring what we (I'm not alone) think is important.
> > 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.
there's no added functionality. There's only occasional luck.
Who's fooling who ?
> If your implementation is good, it should not matter.
hah - I have an idea - you write a depsolver some time and let me know
about it, eh?
Sigh.
> It's not exactly pollution. It's irrelevant to the
version comparison and
> has a whole list of advantages on its own.
how about:
namespace pollution.
you've heard of that, right. Well that's what this is.
Pollution is harmful, this is harmless.
> Well, RPM does it correctly. There's no reason why Yum would
do it
> differently.
rpm doesn't care. It's not affecting rpm b/c rpm DOESN'T DEAL WITH
REPOSITORIES. It doesn't have to sort out anything greater than what you
passed to it on the commandline.
rpm is not a comparison AT ALL.
But Yum does not care about the repotag either. It's harmless.
> 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.
Exactly right, and we as developers have a responsibility to encourage
use of data that is trustworthy. A brand in the release tag is not
trustworthy. We're doing a great disservice to users by encouraging the
pattern.
It's not there to be trustworthy, we have GPG keys for that.
> 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.
No, but we can add the gpg information to the metadata. And then those
tools can rely on it from there.
Sure, tools can rely on something else. The repotag is not harming.
> 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.
I think it's better than replacement for a repotag - it's authoritative
and secure.
Sure, and the repotag does not make it less effective.
> 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.
What do you think we're asking for here? And who is 'red hat' in this
context. We're not asking for a modification to rpm. Nor are we talking
about a modification to many of the tools available. We're talking about
standardization of use and encouraging other information to be used.
How do you think you create standards. Do you think you just fall in
line with things that happened in the past and sigh b/c it isn't the way
you wanted it? No.
YOU MAKE THE STANDARD THAT WORKS BETTER.
Sure, come up with something better without ignoring what we think is
important. I can't think of anything that would work on older
distributions and does what we need.
> If you have a better alternative I gladly accept, but not if it
does not
> conform the current list of advantages.
Read above. I think I just suggested a better alternative and it gains
us A LOT more than your list of defacto advantages.
And you ignored my defacto advantages, while the repotag does not harm
what I do not consider an alternative.
I never proposed the repotag as a replacement for the GPG signature.
-- dag wieers, dag(a)wieers.com,
http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]