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

Neal Gompa ngompa13 at
Sat Oct 10 05:30:00 UTC 2015

On Fri, Oct 9, 2015 at 9:32 PM, Kevin Kofler <kevin.kofler at> wrote:

> 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.

​That's a fair point.

> 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.)

​Then it sounds like it would make more sense to have a mechanism to
automatically add the user-visible version number rather than the soname.
Though, I don't quite understand what the purpose for sonames are in the
first place, if they aren't really designed for supporting parallel
installable stuff...

> 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.
​I don't want to have to unnecessarily munge the name either. For a similar
reason, I don't like the lib/lib64 prefix naming they have to do in order
to work around weaknesses in some of their tooling.​

> > ​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).
​As far as I can tell, %autosetup patch application order is controlled by
your PatchN declarations. I've not seen a circumstance where it works
differently. But that's besides the point. The point I was trying to make
is that we should move towards implementing more standardized mechanisms.​
The other criticisms are fair, but I think %autosetup comes in handy when
you have lots and lots of patches, and you really don't need the
conditional application.

>         Kevin Kofler

真実はいつも一つ!/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list