On 03/28/2013 09:29 AM, juanmabc wrote: > Just today i check updates, gnome-desktop3 was there, i didn't notice it but > it is following the gtk3 naming scheme, and, what i think is happening more > than desired, a lot of packages just kept going doing it. > > I see an overuse or exploit or package names vs versions, which both terms are > very well defined, so should/might do it rpm. While they are well defined I am not sure you are getting the right definition here. The package name and version are not so much a descriptive element that's supposed to be beautiful but a a way of defining update paths. All packages with the same name define a list of updates ordered by the version number. The "package" as a name though also defines a responsibility for further updates. You as packager and owner of a package are responsible to provide updates, bugfixes (to some extend) and especially security fixes. The exact "contract" with your audience may vary but the responsibility for updates is bound to the package name. This is done to make life easier for package maintainers. They can narrow their attention down to the newest version of the package. It is enough to create one new package and you do not have to worry about all the other, previous versions out there. To make this possible we do not allow users to stay with older versions of package (while expecting fixes for them). So this is the base model of package maintenance you should be familiar with. For some packages this is not enough. GNOME is a really bad example as the two "versions" are basically completely different desktops. But of course there are other examples that are more legit. Projects needed in two different, much more related, versions. > I stated a problem, the solution is open. > I am proposing a rpm tag: > - Coexists: package-major > and/or > - Coexists: package-major.minor.bugfix > (whatever fill the technical details), > in the same spirit that Requires:. While this seems easier for the packager as creating a new package with a different name it actually is not. First your suggestion has it the wrong way around. Of course it would need to be something like Updates: package-major telling rpm that this is an update for package-major.* only not for package-othermajor. Otherwise you are going to add new lines for each new major version to all older ones. Let's forget for the moment what to do with packages not containing such a line. Ok, so now we have bumped the major number a couple of times (Think of Python as an example and "major" actually being the minor number. So you have Python-2.0, Python-2.1, Python2.2, Python-2.3, Python-2.4, Python-2.5, ... packages out there) You have a spec file in your dist-git who's history spans all those "major" releases. Now someone tells you that there is a critical bug you need to fix. How many packages do you need to build? How do you know which are the ones? Well, easy. You have a branch for each major release. So you end up with a separate spec file for each major version, too. Just the name is a bit nicer. But you paid for that by adding some weird lines to each spec. So for the packager there is not much to win here. (Not even talking about build infrastructure here.) I'd argue for the users there is not much to win here either. The nicer name comes with a price. The name no longer is sufficient to understand the situation. If you see some packages with the same name you no longer can be sure that "yum install packagename" is what you want. Every time you will need to have a closer look how exactly those packages relate to each other. May be there is only one "newest" package, may be two or three or all of them are. So, I argue actually adding the fixed version to the name is the right thing to do for those situations where an older version needs to be installed beside a newer one. While being ugly it tells the users that there is something special about this package without requiring any special tooling. It keeps the the unity of package maintainer, spec file history and responsibility for updates. If you want something that looks more beautiful look at the "application" installers" that are in the work that avoid using package names completely. Florian -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
