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