Summary/Minutes from today's FESCo Meeting (2015-10-07)

Kevin Kofler kevin.kofler at chello.at
Sat Oct 10 01:32:39 UTC 2015


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



More information about the devel mailing list