On Fri, Oct 9, 2015 at 9:32 PM, Kevin Kofler <kevin.kof...@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 > 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!
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
