Hi Johannes, On 8/14/24 18:57, Johannes Kastl wrote:
Hi all,
for packaging lix I apparently need the coreutils binary. So I tried adding coreutils-single to the BuildRequires, as this contains the binary.
Why do you need the '/bin/coreutils' binary? The 'coreutils-single' package is built using './configure --enable-single-binary ...', which in turn is: $ ./configure --help [...] --enable-single-binary=shebangs|symlinks Compile all the tools in a single binary, reducing the overall size. When compiled this way, shebangs (default when enabled) or symlinks are installed for each tool that points to the single binary. [...] The resulting /bin/coreutils does not usually get called directly, but as a wrapper to all the other coreutils programs: cp, mv, df, du, etc. The coreutils-single package is simply a drop-in replacement of the standard coreutils package, has the same functionality, but saves some MB on disk. I've tested switching between them a couple of times. So what's the point you depend on the coreutils binary at build time of your package?
But then the builds are unresolvable, as lots of other packages depend on coreutils, and the both of them conflict.
Not sure why the "single" package does not just contain the additional binary and does not conflict, but there may be a reason.
How do I solve this without having to resort to crude prjconf hacks?
I'm not the expert in buildservice directives. The package has very well a Conflicts in it - here the snippet of the multi-build spec: %if "%{name}" == "coreutils-single" Conflicts: coreutils Provides: coreutils = %{version}-%{release} %endif
The packages that depend on coreutils are:
rpm-build systemd-rpm-macros debugedit linux-glibc-devel
Maybe those should better depend on specific utilities instead of the package names? ... but again, I'm not an expert in this deps stuff. Have a nice day, Berny