package, package2, package3 naming-with-version exploit

[Florian Festi]

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