Packaging lix for openSUSE: is the coreutils binary really needed? #470
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#470
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi,
I am trying to package lix for openSUSE. One issue I ran into was the dependency on the coreutils binary (not the package).
https://git.lix.systems/lix-project/lix/src/branch/main/meson.build#L339
When searching for usage of the coreutils binary, I fail to spot any actual usage.
https://git.lix.systems/lix-project/lix/search?q=coreutils
Can it be that the requirement is for the coreutils tools to be installed, specifically the
id
andenv
binaries?The reason why I ask is that it is a little harder to get the actual
coreutils
binary on openSUSE, while the coreutils package containing all the different binaries is installed pretty much by default...Kind Regards,
Johannes
I speculate this is possibly a badly written guard against BSD coreutils, maybe inherited from the since removed make build system. @qyriad may know more.
I tried some crude hacks before building, which at least starts the compilation process:
This makes meson look for
id
andenv
instead of thecoreutils
binary.cp ${pkgs.coreutils}/bin/id /tmp/id
ff.
ln -s ${pkgs.coreutils}/bin/env $out/usr/bin/env
And it removes the apparently unused variable from
tests/functional/meson.build
.This way the compilation starts up (it fails later due to unrelated reasons, but at least it starts).
FYI this is a duplicate of #376