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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel