Summary/Minutes from today's FESCo Meeting (2015-10-07)
ngompa13 at gmail.com
Sat Oct 10 05:30:00 UTC 2015
On Fri, Oct 9, 2015 at 9:32 PM, Kevin Kofler <kevin.kofler at chello.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
> 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
> IMHO, shipping a compatibility library needs to be a concious decision by a
> maintainer. A naming scheme that allows abusing old unmaintained packages
> compatibility packages is a recipe for a disaster.
> > Mageia itself has a macro that generates these names, and packagers
> > 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
> > 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
> 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.
> 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
> 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
> 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
> Kevin Kofler
真実はいつも一つ！/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel