Fedora Project launches Pre-Extras

[seth vidal]

> 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.

How confusing and annoying would it be if I decided to make every
package I ever release have a release of 99999.dag.someotherinfo?

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.



> > 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.

give a whoot, don't pollute.



> > 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.

You're just adding a brand.

so adding a tag like 0.fc1.foo is fine.

That's helpful in determining the ver/rel of the package.

Adding 'nike' to it or 'coke' isn't helpful.

it's just advertisement. I understand if you want to be in marketing,
but I think it's useless in this context. :)


> > 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.


> 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?


> 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:

thank you for the useless definition.

how about:
namespace pollution.

you've heard of that, right. Well that's what this is.



> 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.


> 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.

> 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.


> 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.



> 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.



> 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.
-sv