[Rpm-maint] Idea of the day

Vít Ondruch vondruch at redhat.com
Sat Feb 8 12:25:23 UTC 2014

Dne 6.2.2014 13:50, Florian Festi napsal(a):
> Hi!
> While discussing updates and version-in-package-names issues (related to
> a programming language that shall not be named) we came up with the
> following (completely not thought through) idea:
> Offer a special character for separating the version number within the
> package name from the "real" name e.g. "@". While updates would continue
> to work as they do right now and foo at 1-1.2.3 is only do be updated by
> other foo at 1 versions the "@" has the following effects:
> Whenever you query for or address a package (name) you also match the
> part before the @. So you could do rpm -e foo-1.2.3 which would remove
> foo at 1-1.2.3
> Whenever the name or NVR is printed in the UI the part after the @ is
> omitted and the matching part of the number is highlighted if possible:
> foo-*1*.2.3
> May be even automatically add a Provide for the part before the @.
> Benefit of the idea: All "real" operation just keep working as they used
> to. We have the wanted behaviour on the UI of not showing the version
> number twice and matching the name without the version number.
> This feature could also be used for library packages.
> Florian
> _______________________________________________
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint

Hi Florian,

The idea is interesting in deed, however, it misses the point. It might
work, when the versioning scheme is given and clear. It assumes, that
the next version released will follow the scheme. Unfortunately, that is
typically not the case. Name Linux kernel for one. The change from 2.x
versioning to 3.x was completely arbitrary. Your proposal cannot handle it.

Also, although not necessarily wrong, it gives no power to system
administrator to override the scheme. I can imagine, that in some cases,
system administrator should be able to override the upgrade path. I.e.
it is known, that Kernel 3.10 has issue on your particular hardware, but
it has fixed in Kernel 3.13. The system administrator should be able to
redefine the upgrade path and specify, that Kernel 3.1{1,2} should be

Also, it add some magical behavior to RPM and duplicates the version.


More information about the Rpm-maint mailing list