New library package policy

[berolinux]

The library package naming policy used up until 4.3 is in many ways suboptimal for an OS like OpenMandriva LX.

• For people using cooker or rolling, it leaves unneeded artifacts around (e.g. multiple old versions of boost in /usr/lib64 because the old versions never get removed because new libraries have new names -- they get installed as dependencies of newer packages, but the older version never gets removed, and that can't be changed because we want to allow compat packages).
• %_lib in the name is obsolete with rpm supporting multiarch and the filesystem layout changes for 5.0 - no more "lib64" prefixes
• Unnecessary package splits just for the sake of following an outdated policy

The following changes will probably make most sense:

• No more %_lib in the name
• For versioning, the current version of a library doesn't have the soname attached. Compat packages keep the soname in the package name exactly as it is today. e.g. when libavcodec.so.58 is the current version, it comes from a package called just "libavcodec". When an updated ffmpeg includes libavcodec.so.59, that gets the "libavcodec" name while a compat package (if any) for applications that still need libavcodec.so.58 would be named libavcodec58 (same as before). That way, old versions get removed on updates but people needing them can still get them and find them easily
• No more libpackages that aren't necessary. It doesn't make sense to split e.g. libdigikamui7.4.0 out of digikam just because it happens to be technically a shared library file that lives in %_libdir. If a library is a component of an application and not used by anything else, it can and should live in the application's package.

Obviously more changes may be necessary/useful. Don't hesitate to add new ideas or tell me mine are wrong.

[bogdro]

Hi.

I'm not an OS packager, maintainer or whatever, but wanted to share my humble point of view:

• "No more %_lib in the name" - probably a good idea. Although the name clearly says which version someone is installing, so does specifying the architecture. And you don't need to scroll screens up/down in GUI tools like dnfdragora to find the library with the same name but a different "bitness",
• on versioning - don't know. What you say makes sense, but it could be confusing if you have 2 programs: A and B, both require e.g. libavcodec version "58". You upgrade A together libavcodec (to v59). Will B get removed because it still needs the old library? Or would the transaction fail? I mean, e.g. libavcodec58 wouldn't get automatically installed for B, would it? It's probably better to go the way you suggest and let user interfacing tools handle such situations (like offer the upgrade and install the old version to keep program B), if they don't already,
• "No more libpackages that aren't necessary" - this is the primary reason I'm responding. I agree! A separate library package should be present if it's meant for development (like has a matching -devel package). Otherwise - probably makes little sense. And the reason I'm responding here is that during a system upgrade, FileZilla failed to be upgraded, because lib64filezilla23-0.35.0 conflicted with lib64filezilla11-0.26.0 (whatever the versions were; I'm just syaing that they provided the same files etc. and conflicted). Confusing for users. Another solution would be to be very strict about dependencies, replacements, obsoletes, etc. So that e.g. installing new FileZilla installs the new lib(64)filezilla while immediately removing the old one in the same transaction. Probably more work, though.

Thank you!

[tpgxyz]

@bogdro hello, thank yo for your feedback, let me respond to you points:

Ad 1. currently library naming scheme looks like that %{_lib}%{name}%{major}-%{version}-%{release}-%{disttag}.rpm

lib64f2fs8-1.14.0-2-omv4090.x86_64.rpm
lib64f2fs8-1.14.0-2-omv4090.aarch64.rpm

After the change of getting rid of %{_lib} you will get:

libf2fs8-1.14.0-2-omv4090.x86_64.rpm
libf2fs8-1.14.0-2-omv4090.aarch64.rpm

As you may have noticed library naming policy is going to produce still packages with arch name and stuff. These days we are mostly building packages with library prefix starting with "lib64", and this is a useless duplication of %{arch} in rpm filename.

Ad 2. This means libraries are not going to have %{major} in name: lib64f2fs8-1.14.0-2-omv4090.x86_64.rpm After the change it going to look like this: lib64f2fs-1.14.0-2-omv4090.x86_64.rpm

So when f2fs-tools package will get updated, and upstream decides to bump API version from 8 to 9 then we will have this situation: lib64f2fs-1.15.0-1-omv4090.x86_64.rpm If there are any packages that depends on 8 major, then it means we are going to maintain f2fa-tools8 that will generate lib64f2fs8-1.14.0-2-omv4090.x86_64.rpm

Ad 3. This is self explanatory

[bogdro]

@tpgxyz: Hi. Thank you for your response, it confirms I understood right. Well, I just wanted to add my opinion, especially on the 3rd point. I'm sure you'll proceed in the right direction. Keep up the good work!

[tpgxyz]

@bogdro Sure no problem, nevertheless if you see any possible issues feel free to share with us.