Building a package using busybox-coreutils or coreutils-single
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. 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? The packages that depend on coreutils are: rpm-build systemd-rpm-macros debugedit linux-glibc-devel I also tried if busybox-coreutils might solve this, but the problem is the same, as this also conflicts with coreutils... Kind Regards, Johannes
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
On Aug 22 2024, Bernhard Voelker wrote:
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?
Moreover, it's an implementation detail. It could be called /bin/wrdlbrmpfd or whatever. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Hi Bernhard, On 22.08.24 08:23 Bernhard Voelker wrote:
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?
Because that is what upstream has in their meson configuration. I have packaged it in the meantime to depend on the binaries that are actually used. So the problem is solved, but the general issue still persist:
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.
Hmm, in the container I tested all tools were still present, in addition to the coreutils-single binary. Or maybe I misremember?
So what's the point you depend on the coreutils binary at build time of your package?
see above.
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.
I wonder why those packages are not satisfied by the "Provides" that the coreutils-single package apparently has (as you showed above)? If both packages are interchangeable, this should also be possible in OBS (IMHO). Right? Kind Regards, Johannes
Johannes Kastl <mail@johannes-kastl.de> writes:
Hi Bernhard,
On 22.08.24 08:23 Bernhard Voelker wrote:
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?
Because that is what upstream has in their meson configuration.
Why does the binary need to be visible in path if it's never to be called directly? Libexec would be the better place. Upstream putting it into /bin is not a good reason to put it there IMHO.
Hi Björn, On 13.09.24 16:29 Björn Bidar wrote:
Johannes Kastl <mail@johannes-kastl.de> writes:
On 22.08.24 08:23 Bernhard Voelker wrote:
Why do you need the '/bin/coreutils' binary?
Because that is what upstream has in their meson configuration.
Why does the binary need to be visible in path if it's never to be called directly? Libexec would be the better place.
Upstream putting it into /bin is not a good reason to put it there IMHO.
I was talking about the lix package (my "upstream") having a dependency on the coreutils binary in their meson configuration. Why coreutils-single puts the binary in that place is up to the packager or the upstream. And completely irrelevant for this discussion on how to build packages with coreutils-single, ain't it? Kind Regards, Johannes
On 9/13/24 16:29, Björn Bidar wrote:
Why does the binary need to be visible in path if it's never to be called directly? Libexec would be the better place.
Upstream putting it into /bin is not a good reason to put it there IMHO.
It can indeed be called directly: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/coreutils.c?h=v9.5#... Have a nice day, Berny
participants (4)
-
Andreas Schwab -
Bernhard Voelker -
Björn Bidar -
Johannes Kastl