package, package2, package3 naming-with-version exploit

[juanmabc]

I see from a first glance that the main reason to keep this way is gonna be 
easy packaging and less trouble.

To the easiness, i am pretty sure that it would me much easier to run an 
existing operative system than developing a completely rewritten from scratch 
as Linux, yet it happened for some technical reasons, fighting against the 
easiness with happiness about the right thing to do. So if easy is going to be 
a reason to keep that way, we are drifting to some place were it would 
probably bite us at some point. To emphasize, i guess would be easier to untar 
a package.tbz2 than create a rpm format, etc. again the technical reasons made 
it happen. So easier is from my point of view no obstacle for it. If "easy 
this way" is a reason, i'd say I care better about right, smart, better. So I 
hope you also say that it is easy but it is also the right, smart and better 
way to do it.

Less trouble is a derivative of the previous, but the fact just points out 
that there is some concern, some feeling that it is not right, yet by now that 
way just works, though it is creating a growing sense of hack in the repos 
(pkg3, pkg314, ...).

Some views state that packaging just needs to think of update paths and in 
some way imply that this stuff is not meant to be shown to the user so whatever 
the packages are named it is/should not be really exposed or intended to be 
exposed to the user. Just like assembler code that works, but are not expected 
to be read (minijoke, of course, some assembler coders do/will read it). Now, 
yet, i pertain to the group that will think that while not read or viewed or 
machine interpreted or not ever shown/exposed it should be right, clever, 
smart and interesting. That is what we (me too, and i guess not all) computer 
technicians call style, despite the myth that is just like aesthetic, a shower 
also cleans bacteria. So at the end i point out that ugly is not "ewww, what a 
result, yet works", but "wrong, something does not fit, rethink and solve it 
right".

It would be nice to solve pkg, pkg2, pkg3 issues with some:
- pkg-1.spec
- pkg-2.spec
- pkg-3.spec
and yum install pkg-1 pkg-2
resulting in
- pkg-1.0.x installed (and with its own updates)
- pkg-2.0.x installed (and with its own updates)
note the difference, *point and cause of all here*, from
- pkg-1.0.x
- pkg2-2.0.x
I guess major version of a package can provide more info to be used than it 
does now, and rpm didn't think on multiversion with update paths from start.

I'll check more mailing when i got time, thanks.