Static libraries do not exist in most of the distributions and it is not the 
In this exact context adding today in .pc files Requires.private and 
Libs.private is pointless.
More than 14 years ago in first Solaris 10 distribution release have been no 
longer shipped libc and libm.
Currently, Solaris 11 has no at all static libraries with only a few exceptions 
like static flex library.
In Fedora static libraries are no longer widely used except few scenarios:
1. link static binaries used by some test suites
2. provide static libraries which have no stable ABI interface like binutils 

The main reason why static linking is no longer widely used are security 
reasons. In case of any CVEs in libraries used in some statically linked 
binaries, it is necessary to rebuild all those binaries In case libraries as 
DSO is only necessary to rebuild package which provides affected binary.
The second reason why static binaries should not be used are ABI changes. Using 
static linking makes those changes way harder to maintain.

Nevertheless, in all Linux, *BSD, Solaris and other systems distributions use 
Requires.private should be used only if someone is thinking that library A 
provided by package B might be used to produce statically linked binaries using 
the library A. Effectively this is no longer possible and if something is 
linking with the library A it means in ~99.99% dynamic linking.

Generate pkgconfig dependences for dynamic linking using static linking 
scenario produces redundant dependencies.
Adding automatically pkgconfig to package Requires is the second part of 
redundant dependencies generated by current scripts/ script.

The second change is just dumb, because the pkgconfig implementation is 
necessary for even using it, and ensures that build scripts that implicitly 
expect pkgconfig to be available for querying the file will work.
This is chicken and egg problem and the result of the assumption that if 
package A has "Provide: pkgconfig(foo)" it does not mean that this will be used 
in another package spec file *always* in form of "BuildRequires: 
pkgconfig(foo)". This is not the typical case because many packages still do 
not use pkgconfig on checking for example foo library.
The simple solution of this wrings solution is to add "BuildRequires: 
pkgconfig" if "BuuildRequires: pkgconfig(foo)" is used. Nevertheless, this 
workaround *is not needed* as current rpm-build package requires pkgconfig.
In other words on building any package from spec file which has "BuildRequires: 
pkgconfig(foo)" using rpmbuild command accessibility to pkg-conf command us 
guaranteed by rpm-build package Requires.
As long as install rpmbuild will cause instantly install pkgconfig spreading 
across many other packages "Requires: pkgconfig" is 100% redundant.

Many packages provides .pc files and they are not used on building other 

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to