Neal Gompa wrote:
> At this point in time, Fedora is the only major distribution I know of
> that doesn't use versioned shared library package names. Both SUSE and
> Mageia do, and of course the Debian/Ubuntu family does. I've spoken to
> folks working in both SUSE and Mageia (especially Mageia as of late), and
> I've heard that there's a particular eagerness to find a way to have RPM
> generate these versioned library names for packages.
Debian has to use it because dpkg does not support soname dependencies. But
for RPM-based distributions, it just does not make sense. The only thing it
allows (that the soname AutoProvides and AutoRequires don't already handle)
is to attempt to parallel-install libraries for which this is NOT supported,
which is a recipe for:
1. security issues, because you are using an obsolete unmaintained library
version without realizing it (because nothing will replace your libfoo1
if the current version of your distribution ships libfoo2 instead), and
2. file conflicts, because nobody tested parallel installation of the 2
versions.
IMHO, shipping a compatibility library needs to be a concious decision by a
maintainer. A naming scheme that allows abusing old unmaintained packages as
compatibility packages is a recipe for a disaster.
> Mageia itself has a macro that generates these names, and packagers merely
> have to utilize them to get the appropriate name generation. Part of that
> is because of the quirks of urpmi and supporting multilib, but I don't see
> why we couldn't work with the other two distros to develop a standardized
> soname suffix generator that could simply be activated as a flag on a
> subpackage.
The Mageia soversion macros are a horrible overengineered mess that leads to
unreadable and overcomplicated spec files. Please do NOT pollute Fedora
packages with such completely unnecessary macros.
I also think our naming scheme for libraries makes a lot more sense:
1. The default version of the library typically has NO version suffix. Thus:
1.1. It is obvious to users which version is the default.
1.2. The package names for the default version are simpler.
2. Compatibility libraries are normally named after the user-visible
version, NOT the soversion. E.g., if we ship libfoo 0.10 as a
compatibility library, we ship it as libfoo010, not something like
libfoo7. Soversion-based naming is particularly misleading for kdelibs,
where kdelibs 3 has the soversion 4 and kdelibs 4 has the soversion 5.
(The new KDE Frameworks 5 now typically also have 5 as their soversion,
the libraries have new names (libKF5*.so) so they don't conflict. But as
long as older kdelibs still exist, that just adds to the confusion.) Our
kdelibs 3 package is called kdelibs3, not kdelibs4, which would be
extremely misleading. Debian used kdelibs4c2a for kdelibs 3 and kdelibs5
for kdelibs 4! (The "c2a" is another unreadable mess because they decided
to encode the C++ ABI in the package name. We just did a mass rebuild on
a flag day and were done with it.)
3. There is also no requirement that library package names start with
"lib*". This should also stay that way. E.g., upstream thinks of glib as
glib, not libglib (a particularly silly name, by the way). So we should
not unnecessarily munge the name.
> IMO, it would be very nice if we could come together and hash out a
> standardized approach to things. We've done it with %autosetup,
> %autopatch, %make_build / %make_install, and a number of other things in
> RPM, I don't see why we can't for this too.
%autosetup is an inflexible nonsense that just does not work in many setups
(no control over the application order of the patches, no control over the
switches passed to patch, no way to conditionally apply patches, etc.), and
also does not help specfile readability. I refuse to use %autosetup in my
packages and will yell at anybody that dares changing one of my packages to
use it (and revert the commit).
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
