Let's focus on the guidelines for the static-only libraries, currently it states:
Static libraries only. When a package only provides static libraries you MAY place all the static library files in the *-devel subpackage. When doing this you also MUST have a virtual Provide for the *-static package: %package devel Provides: foo-static = %{version}-%{release} Packages which explicitly need to link against the static version MUST BuildRequire: foo-static, so that the usage can be tracked. Packaging Header Only Libraries Place all of the header files in the *-devel subpackage and then you must have a virtual Provide for the *-static package: %package devel Provides: foo-static = %{version}-%{release} Packages which use the header library must BuildRequire: foo-static, so that the usage can be tracked.
%package devel Provides: foo-static = %{version}-%{release}
Packages which explicitly need to link against the static version MUST BuildRequire: foo-static, so that the usage can be tracked.
BuildRequire: foo-static
Place all of the header files in the *-devel subpackage and then you must have a virtual Provide for the *-static package:
Packages which use the header library must BuildRequire: foo-static, so that the usage can be tracked.
My comment on this guideline, can the requirement of BuildRequire: foo-static be relaxed in the case of static/header-only packages? What tool is being used that require *-static format, and why can't the check be refined to check if Provides: *-static is present and then use BuildRequire: foo-devel instead.
*-static
Provides: *-static
BuildRequire: foo-devel
The reason I bring this up is because I believe it would be more beneficial to use build-system related Provides (e.g. cmake(foo) or pkg-config(foo)) instead since that better reflects what is actually being used in the build system and it creates less burden on the user of package foo to determine where the actual package is located and what type of package is. (The burden of the packager foo to makes sure it Provides: *-static is unaffected.)
Provides
cmake(foo)
pkg-config(foo)
foo
The historical reason for this requirement comes down to it being difficult to query using repoquery on the SRPM repo without explicitly doing this.
repoquery
Thanks for the insight. Do we still need to keep that restrictions given the capabilities of tools like fedrq? Maybe if we request/implement a specific helper function to make the query more straightforward?
fedrq
What I am trying to get at is what would we need to improve this process. Presumably we can even reduce the Provides: *-static if this can be automatically populated like the python3dist.
python3dist
Log in to comment on this ticket.