Dividing packages into main and dimensional parts looks like a well-established practice that saves space for those who do not create software. On Linux, a library that uses SONAME version control can have two or more files representing one library, for example:
- libABC.so is a linker script, for example.
INPUT (libABC.so.1) - libABC.so.1 - real binary
Where the .so file is really used only during build, redirecting the actual dependency on the versioned file. If so, should it not be placed in, for example, libABC-devel.rpmalong with include files? It is wrong to put both files in a run-time package, for example. libABC.rpm.
eg. one observation, if you check ls /usr/lib/lib*.so*, many file versions do not have a matching pair lib*.so.
I also noticed that, for example, Fedora and Conda-forge Support replace these linker scripts with symbolic links ( 1 , 2 ) and pack them along with the main binary. Is there any reason to do this despite the fact that the source library is building linker scripts?
I will accept an answer that summarizes the arguments for one way or another to package linker scripts in runtime / devel for discussion with accompanying packages.
Anton source
share