On Sun, Jul 23, 2006 at 08:42:52AM -0500, Tom 'spot' Callaway wrote:
On Sat, 2006-07-22 at 23:39 -0700, Panu Matilainen wrote:
> The name is used for versioning in several other packages for similar
> reasons (to *sanely* allow more than one version of the package
> simultaneously installed and updated), for example:
>
> [pmatilai@cs181077098 ~]$ repoquery 'openssl*'
> openssl-perl-0:0.9.8a-5.2.i386
> openssl097a-0:0.9.7a-4.2.1.i386
> openssl-0:0.9.8a-5.2.i686
> openssl-devel-0:0.9.8a-5.2.i386
> openssl-0:0.9.8a-5.2.i386
> [pmatilai@cs181077098 ~]$ repoquery 'libpng*'
> libpng-devel-2:1.2.8-2.2.1.i386
> libpng10-0:1.0.18-3.2.1.i386
> libpng-2:1.2.8-2.2.1.i386
> libpng10-devel-0:1.0.18-3.2.1.i386
And I personally think those are abuses of %{NAME}. I'd much rather see
the compat-* ideology used there instead of overloading Name.
compat-* is overloading the name just the same.
There are dozens of further examples, gcc<XYZ>, autoconf<XYZ>,
automake<XYZ>, gtk2 (or let's say g*2), libstdc++so<XYZ>,
mysqlclient<XYZ> and so on.
A quick check on current rawhide shows that at least 5% of the
src.rpms are overloading the name.
I really had to fight with myself long before I accepted that there is
no other way that uname-r-in-the-name. It hurts my eyes just as it
does anyone's else, but it proves to be a neccessity.
Let me put it this way:
Unless someone can show me a solid write-up that shows that there is
_NO_ way to handle kernel modules without overloading Name, I'm
going to oppose it on principle.
It's in the posts by Thorsten and myself including an example
even, the summary is that
There is no way to handle kernel modules for several kernels w/o
using a uname-r disambiguation in the name on rpm level.
That's a fact. You either get to
a) ban usage of rpm CLI and patch all depsolvers to follow non-rpm
ordering
b) stop supporting more than the very latest published kernel
(e.g. allowing the current kernel to nuke/overwrite its own kernel
modules while upgrading/installing a new kernel)
c) accept uname -r in the name
There is disagreement about how bad a) is. I consider it a blocker,
Thorsten can live with it. So currently we are effectively living in
a), only that noone knows that rpm CLI usage is disallowed with kernel
module packages.
c) is the only technical sensible solution bringing us at 90% of the
target with only one drawback: Ugly names. So what, technical
aesthetics superseed what meets the eye. :)
--
Axel.Thimm at
ATrpms.net