Bruno Haible <[email protected]> writes:
>> That would be okay if build-essential was used as intended, i.e., only
>> packages required for building Debian packages depended on it, but that
>> is not the case in practice. See a few notable examples that make it
>> unlikely that you can actually use GNU coreutils on that distribution:
>>
>> cuda-crt-13-1
>> cuda-nvcc-13-1
>> cuda-crt-13-1
>> python3-virtualenv
>> python3-torch-rocm
>> python3-torch
>> python3-pip
>> pyenv
>> opam
>> nim
>> gnulib
>> flex
>>
>> Those were taken from the output of the following command:
>>
>> $ apt-cache rdepends build-essential
>
> Right. I noticed the conflict with 'opam' by myself, and now mention
> your 'apt-cache rdepends' command in a blog post:
> https://dev.to/bhaible/ubuntu-kubuntu-2604-prefer-gnu-coreutils-c01
>
>> Perhaps 'flex' will cause problems for some packages you maintain CI
>> for
>
> Strange: I did not get a problem with 'flex'. Maybe that dependency has
> only been added recently?
Interesting. I'm not very familiar with dpkg or apt, but I guess it's
because that command shows suggested and recommended packages by
default:
$ apt-cache rdepends --no-recommends --no-suggests \
build-essential
At least, that one doesn't show 'flex'.
>> In the meantime, here is the only way I have found to use GNU coreutils
>> there:
>>
>> $ podman run --rm -it ubuntu:26.04
>> $ apt update -y && apt upgrade -y && echo $?
>> [...]
>> 0
>> $ apt install equivs
>> [...]
>> $ mkdir -p tmp; cd tmp
>> $ apt remove --allow-remove-essential coreutils-from-uutils
>> [...]
>> $ cat <<\EOF > uutils
>> Source: coreutils-from
>> Section: utils
>> Priority: optional
>> Standards-Version: 4.6.2
>>
>> Package: coreutils-from-uutils
>> Description: :)
>> EOF
>> $ equivs-build uutils
>> [...]
>> $ dpkg -i coreutils-from-uutils_1.0_all.deb
>> $ dpkg -l | grep coreutils-from
>> ii coreutils-from-gnu 0.0.0~ubuntu25
>> all coreutils from the GNU coreutils project
>> ii coreutils-from-uutils 1.0
>> all Dummy package to fulfill package dependencies
>>
>> Of course, that is a complete hack and may break your system in strange
>> and unexpected ways, if not now, then sometime in the unforeseen future.
>
> Should I add this recipe to the blog post?
Fine with me, as long as it has a warning that it isn't a supported
method of doing things. A better solution would be to use a different
distribution wherever possible.
Collin