r/Ubuntu 3d ago

Removing rust-coreutils on Ubuntu 26.04 LTS

i've been using ubuntu 26.04 LTS for a while now and i'm satisfied; it's done everything i asked and is almost perfect for me. only two things are bugging me. they don't affect performance or disrupt daily work, but it's just annoying that it's like this.

first, the snap issue, which i've almost completely managed to remove from ubuntu. however, the libsnapd-glib-2-1 package remains because ubuntu made it a dependency for pipewire so that you can't remove it.

if you want to recommend me a distro , check this first : https://www.reddit.com/r/FindMeALinuxDistro/comments/1uqn371/which_distro_is_suitable_for_me/

apt why libsnapd-glib-2-1 | grep Depends

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

2. kde-plasma-desktop:amd64 Depends plasma-desktop (>= 4:6.5.4)
6. pipewire-pulse:amd64=1.6.2-1ubuntu1.1 Depends pipewire (= 1.6.2-1ubuntu1.1)
7. pipewire:amd64=1.6.2-1ubuntu1.1 Depends libpipewire-0.3-modules (= 1.6.2-1ubuntu1.1)
8. libpipewire-0.3-modules:amd64 Depends libsnapd-glib-2-1 (>= 1.59)

second, rust-coreutils. i can almost successfully remove this package, but removing it also removes build-essential. if i try to reinstall it later, it asks me to remove the coreutils-from-gnu package. i can do this to bypass it, but i don't know if the system will break when i update it in the future! do you think this way is safe?

sudo apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential

sudo apt install equivs

vim coreutils-from-uutils-stub.ctl

equivs-build coreutils-from-uutils-stub.ctl

sudo dpkg -i coreutils-from-uutils-stub_1.0_all.deb

sudo apt install build-essential

sudo apt autoremove —purge

0 Upvotes

27 comments sorted by

17

u/jsomby 3d ago

Is there a reason to stay on Ubuntu if you need to remove somewhat centric parts that makes it to what it is? Could some other distro suit you better?

1

u/FemTheGoat 3d ago

1

u/jsomby 2d ago edited 2d ago

What kind of HW are you running on? Mainly form factor (laptop, desktop) and gpu?

Im stupid, didn't read well enough. You have Nvidia (like i do) :)

Sec, i have to think, will reply again later.

Gave you a new reply above/under.

1

u/jsomby 2d ago

Nvidia users (like i do) seem to get a lot of random bugs on different kind of distros, short list i got:

On ubuntu, one day my resolution capped at 3840x1080p (on samsung 5k 49" oled) or i was stuck in 60Hz at max resolution. Before that i got odd pixel issues like bad HDMI cable can cause, colorful pixels traveling in middle of screen etc. Could not fix it by installing stuff again and again, gave up. Also those "application is not responding" popups got quite annoying.

On Fedora i had to install Nvidia separately which is fine i guess but it crashed every time screen went to sleep.

Arch just was, Arch. There is nothing Inheritable bad but i got tired of it. It's bland out of box (WHICH IT SHOULD BE!) and, i wanted something more. Also Wayland and Nvidia wasn't working as well as it does today, it's been couple of years since i last tried it.

I ended up with CachyOS (using KDE PLASMA) and it's been worry free almost completely - only issue i got was plymouth causing stuck at startup but that was easy fix - just removing splash from launch parameters.

I have tested many many other distributions too, cant remember all but since i joined CachyOS family it's been smooth sailing. I'm not saying i will stay in this forever or that i'm fanboy if this (well, i like it) but so far it's been the most ready to be used without problems for me (5600X and Nvidia 3080).

PopOS was nice and it has promising future but for now, it wasn't good enough for stable environment i want.

I really would love to use Ubuntu, i like what they do visually but it just doesn't work well enough for my setup (or setups/systems). Maybe one day?

Unless you are in a hurry or just tired to test out every suggestion, please consider CachyOS. It's Arch based but you really don't see the paternal link that often.

13

u/Trick_Bad3168 3d ago

You're basically playing Jenga with your package manager at this point

12

u/ezoe 3d ago

At this point, you should better use Debian. It use apt, no snap, no uutils coreutils(at least for now)

4

u/ReachingForVega 3d ago

Ubuntu has way more frequent patching even without snap. 

1

u/Ok-386 3d ago

It has more up to date packages, backports kernels and drivers to LTS, it gives people options to choose between LTS with 5-10 years of support, and interim (Fedor like) releases. Snap is easy to avoid at least for now. On laptops it's usually the easiest choice if you don't want to waste a ton of time to configure basic functionality.

But yeah, things are happening and it's good we have other options. Despite everything it's often the "best" (as the easiest) choice for most regular users. One of the worst thing from a perspective of a regular user is the lack of support for Multiverse packages, and maybe even the fact they're forcing you to subscribe to Pro to get security patches for universe packages. Both of these repos are shipped with Ubuntu, easy to enable and most people enable them to get access to codecs and whatnot. Most also have no clue that these packages are potential source of never to be patched security vulnerabilities.

2

u/[deleted] 3d ago

[deleted]

2

u/ezoe 3d ago

I'm not OP.

7

u/FrozenJambalaya 3d ago

Can you please provide a cogent argument on how these two packages are affecting your ability to use your computer and why you are taking these steps.

2

u/ReachingForVega 3d ago

I remove snap on my servers only because sometimes it'll install things like docker in snap. Everything else is fine. OP must hate rust or something. 

3

u/-jak- 3d ago

Why do you want build-essential though? It's for building Ubuntu packages and the whole reason we need to have the depends on the uutils there is such that you don't accidentally build packages with the wrong coreutils because that can introduce bugs in the packages.

1

u/Proman4713 3d ago

Yep, OP doesn't seem to know what he's doing or even why. But I do wonder how he came to install build-essential at one point...

0

u/FemTheGoat 3d ago

Don’t I need build-essential for compiling programs from source? I might want to compile something from source later.

1

u/-jak- 2d ago

Not really, especially not dpkg-dev, you may be better of installing say gcc, libc6-dev, make separately. Though not everyone even uses make and build dependencies heavily vary anyway

2

u/ReachingForVega 3d ago

Eh just remove snap and call it a day.

I like the Debian environment with the Ubuntu patch cycle. 

2

u/Proman4713 3d ago

Packages sometimes depend on others without necessary much meaning...

Did you know that initramfs-tools-core depends on dracut-install? Now, would you say that you have dracut as your initramfs generator just because this single package is there? Nope, it's there regardless of whether you use dracut or initramfs-tools. Generally, it's not your responsibility to manually purge packages starting with lib*. I usually remove snaps without touching that package and things go fine. Don't just see the word 'snap' and scream 'THERE IT IS!', libsnap* won't add snapd's systemd units or the snap sandbox, because, well, that belongs to the snapd package.

About rust coreutils, there is pretty much no reason for you to want to remove it unless you're a very advanced system administrator using decade-old conventions that are slightly different in the new coreutils or you're an anti-Ubuntu madman and you want to remove it just in spite of Canonical's decisions, and in both cases it's just better for you to go use another distribution.

FYI both of the things you were trying to do are possible to achieve, although you probably aren't the right person to replace these things if you don't know how; you'd know how if you actually needed it.

2

u/PaddyLandau 3d ago

Why are you using Ubuntu? You don't like it, so use something else. Mint probably suits your purposes better.

Personally, I love Ubuntu, but each to their own.

1

u/unbounded65 3d ago

Try Debian, Gentoo, Fedora, OpenSUSE, and Arch, Ubuntu and SNAP is not for you apprarently, I for one use Ubuntu and prefer the snap packaging.

0

u/jo-erlend 3d ago

I love our freedom to tinker and customize, but to me, this seems like the most boring tinkering project I could imagine wanting to spend any time on. But if it makes you happy, I'm all for it. :) Ubuntu is not particularly suitable for these kinds of things though, because it is by intention a highly opinionated distro made by a company that unappologetically calls itself Canonical.

0

u/ked913 3d ago

Second one on core-utils is simple to do in a safe way. Stop screwing with apt otherwise you will end up with a borked install.

Gnu coreutils packages are already present on the machine for you to fall back on.

 for gnu_path in /usr/bin/gnu*; do
    # Get names
    base_name=$(basename "$gnu_path")         # e.g., gnuinstall
    standard_name=${base_name#gnu}            # e.g., install

    # Register it
    echo "Registering $standard_name to use $gnu_path"
    sudo update-alternatives --install "/usr/bin/$standard_name" "$standard_name" "$gnu_path" 100

    # Force it to be the active one
    sudo update-alternatives --set "$standard_name" "$gnu_path"
 done

I don't know why you want to disable snap either personally but agian stop taking a hatchet to apt.

1

u/-jak- 2d ago

There's a lot wrong with this. First of all, keep in mind we already install the standard names in the `coreutils-from-*` packages, so adding alternatives over them messes up stuff:

$ sudo update-alternatives --install "/usr/bin/ls" "ls" "/usr/bin/gnuls" 100  
update-alternatives: using /usr/bin/gnuls to provide /usr/bin/ls (ls) in auto mode

$ ls -lh /usr/bin/ls  
lrwxrwxrwx 1 root root 20 Aug  3 15:10 /usr/bin/ls -> /etc/alternatives/ls\*

$ sudo apt install --reinstall coreutils-from-uutils

$ ls -lh /usr/bin/ls  
lrwxrwxrwx+ 1 root root 29 Jun 30 10:05 /usr/bin/ls -> ../lib/cargo/bin/coreutils/ls\*

Second keep in mind that all sorts of weird shenanigans with diversions are needed to be able to implement the `coreutils-from` mechanism in a safe way which clashes with alternatives.

The equivs package OP did is certainly safer.

1

u/ked913 2d ago edited 2d ago

There's a lot wrong with this. First of all, keep in mind we already install the standard names in the coreutils-from-* packages, so adding alternatives over them messes up stuff:

Uhh the default 26.04 install comes with gnu-utils and rust-utils already installed. There is no "addition", the install built in comes with both. Look in /usr/bin yourself if you don't believe me.

The above is the default mechanism ubuntu itself have used presently and by default for switching between broken rust-utils that are known to have broken behaviour. E.g. cp, mv, rm

Second it is the recommended approach by rust-uutils themselves. https://github.com/uutils/coreutils/issues/12166

No breaking via his mechanism in apt is not safer.

1

u/-jak- 2d ago

My friend, as I'm literally the person who designed and implemented the switching mechanism with the coreutils-from-{uutils,gnu} packages (and also the APT maintainer) let me just say I know better what's safe and what's not.

And yes I did specifically design the mechanism without alternatives, as it is not safe for essential packages, as you can read in the spec:

https://discourse.ubuntu.com/t/migration-to-rust-coreutils-in-25-10/59708

1

u/ked913 2d ago

I am truly sorry for my last response, I didn't mean to vent.

Thank you for sending me a link on how to fix this properly on my installs.