Separating packages into main and -devel parts looks like a good established practice, which allows to save some space for those who are not building software. On Linux, a library that uses SONAME versioning can have two or more files representing a single library, e.g.:
- libABC.so - linker script, e.g.
INPUT (libABC.so.1) - libABC.so.1 - real binary
Where .so file is really used at the build time only, redirecting actual dependency to the versioned file. If so, shouldn't it be placed into e.g. libABC-devel.rpm along with include files? It looks inappropriate to put both files to a run-time package, e.g. libABC.rpm.
E.g. one observation, if you inspect ls /usr/lib/lib*.so*, many of versioned files do not have corresponding lib*.so pair.
I also noticed that e.g. Fedora and Conda-forge maintainers replace these linker scripts with symlinks (1, 2) and package them along with the main binary. Is there any reason to do that despite that original library builds linker scripts instead?
I'll accept an answer which summarizes arguments for one or another way of packaging linker scripts into runtime/devel for sake of discussion with package maintainers.
