Fedora Project launches Pre-Extras

[Dag Wieers]

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