Another massive tumbleweed is being processed. In between these updeates, I try to cull out (remove) files I know i don’t use. But I see the files I removed are being reloaded. Example would be the ghc (glasgow compiler) , brltty (braille) support, language files, like vietnamese, that I will never use.
Why are many removed files added back during the major updates. These updates are 6000 files on my system. From what file list is this update developed?
I remove hundreds of files and they keep coming back.
Did you read my message? I don’t need to get continually belittled and castigated for criticizing the 6500 updates, my issue is why do items I removed get added back.
When i removed them there was no indication that some major app was to be crippled. You would think that would show up. So why would an app bring them back?
My update will be going for several more hours, I can’t run the zypper dup --no-recommends
Likely a pattern, not an app? Patterns typically recommend packages and do not require them, so if you remove a package you do not break that pattern.
But when a (large) update upgrades some patterns as well, they bring back all their recommended packages, unless you use --no-recommends of course or you uninstall said patterns as well.
And if your upgrade is still in the “preload” or download phase, you can still stop it by CTRL+C; but please don’t do that if it is already in the install phase.
The mitigation how to prevent this is exactly described in my tips.
Different ppl already tried to explain you how --recommends, patterns and dependencies work. So the answer to your question was given several times. What else do you expect?
I didn’t critisice your 6500 packages. But one could get the feeling, that you don’t read the answers which different ppl give you in your threads. It is not the first time that you ask the same question regarding the amount of packages to update. You need to start appliying the mitigations and tips which you get…or you might ask the same question again with the next big update.
I tried once finding a pattern that included the ghc files and couldn’t.
So if I understand properly, if I have any single file from a pattern installed then the entire pattern will be reinstalled upon the major updates unless the --no-recommends is applied.
So the brltty (braille) files get added back if one file from the Accessibility pattern is installed.
It is not all about patterns. There are also dependencies and recommends.
A pattern is a kind of meta package which installs a predefined set of packages. E.g. a game pattern. If you uninstall a package of the pattern, the next time the pattern get update the game will be reinstalled. So you need to uninstall the pattern.
A dependency…is a dependency. When you uninstall a dependency of package x, x will get uninstalled (unless you chose to break a package).
And there are recommended packages. E.g. kdenlive recommends several codec packages. But you don’t nned to install recommended packages. You can prevent installation of the recommended packages by using --no-recommends. See the impressive example i gave here and in the next comment. You need to use zypper in --no-recommeds or zypper dup --no-recommends or the next time when an update comes, recommended packages will get installed again.
In your case, a recommeds is the most likely case why ghc gets pulled in again. And it is not the main ghc package as it is not recommended by anything. But one oft the ghc-* subpackages might get recommended by one of your installed packages, which in return tries to pull in the complete ghc stack.
When you perform a zypper dup operation, there is a summary, before you start the download and before any package installation/deinstallation is performed. It is seperated into several categories:
amount of packages to update
amount of patterns to update
amount of NEW packages which get installed
amount of NEW patterns which get installed
amount of packages to remove
This summary is the point where the user/administrator need to do a basic check and not simply hit yes to proceed with the upgrade/installation.
When you see that a high amount of NEW packages/patterns will get installed, do NOT simply type yes to procede. Hit no! Than try the zypper dup operation with zypper dup --no-recommends. And when in the summary, the NEW packages won’t show up you can proceded with the update. If the high amount of NEW packages is still there you might need to dig a little bit deeper (factory mailing list, NEWS, forum, …) which package recommends or pulls in this NEW packages.
Tumbleweed is a little bit more difficult than Leap and requires a little bit more finetuning from the user/administrator. And one sometimes needs to take a step back before hitting yes to install an update and check how to prevent installation of several 100 unneeded/unwanted packages.
Also, if you’re removing packages you don’t want, you might be successful in preventing them from being reinstalled by locking them after removing them.
Note that it’s a little unclear as well what exactly you’re doing, because you say you’re removing “files”, not “packages”. So if you’re deleting files but not doing something to prevent the package from being updated/reinstalled, then what you’re seeing is what I would expect.
That 6500 packages is too much. Your machine is really bloated.
I have one tumbleweed on another partition of this machine with kde, gnome, xfce4,
labwc, hyprland and wayfire and applications that I normally use and it reaches only a little more than 5000 packages during a major snapshot upgrade.
You can permanently disable recommends to avoid some additional packages in yast2 or myrlyn. I remember there was a save button in yast2 before It might still be there.
I just did a zypper dup and received 2415 updates (my system has a total of 2627 packets installed).
There are several possible reasons why your system has such a large number of packages installed:
zypper is set to install recommended packages (default behavior)
there are pattern installed (default behavior)
individually installed packets
If 1. and 2. apply to your system you will have to manually delete and lock the packets you do not want in your system. If you do not lock them they will come back with the next update.
My system is set to not install any patterns or recommended packets.
I don’t use flatpacks, appimages or other containers unless absolutely necessary as I abhor them. I put time into compiling my own version rather than use containers.
Why have a full featured OS distro if you are installing mini OS repeatedly along with each containerized app. Pretty soon all the OS distros will evolve into a simple system to just be able to run containers instead of being full featured where you can do things on your own.
@tckosvic your missing the point, you have for example distrobox and Tumbleweed, you compile the app and all the development tools in that container without polluting your primary system with tools that are not needed and can cause issues for you. Screw something up in a container and it doesn’t break your system… or require updating 7000 packages along with all the issues you seem to have…
No different that building rpm’s with osc, the whole build process is contained in a build-root and doesn’t interfere with the system…
It seems you missed the point. We understand that you build your own apps and stuff. But your way of doing it is not the best way. You build your apps on the host system and thus cluttered your host with sveral 1000s of dependencies and devel packages. You lost the overview over these amount of packages.
That is why several ppl gave you the recommendation to build your packages outside of your host. Lets say a normal TW installation has ~3000 packages. You want to build an app. Fire up an container or VM, build your app inside it (this will install some 100s or 1000s build dependencies in the VM/container). After the app is built, throw away the VM/container. Your host will still have the basic ~3000 packages and is not cluttered with build dependencies.
If you would build your stuff like that, you won’t loose control over your host as it seems to be happened to you.
I understand it is best to build apps in a container to avoid misc stuff everywhere. But, I am where I am after decades of evolution.
My comments on containers were not directed at building apps but were directed at just getting a new app and using it in a container rather than trying to build it yourself.
Would you rather have a bunch of self-extracting binary blob .run files that break in mysterious, incomprehensible ways and consider all your linux games broken on next glibc update?
Why not just embrace the fact that;
btrfs merges duplicate extents (data)
containers merges duplicate layers
flatpak has a very compatible runtime (carefree to license concerns)
distrobox provides the shell wrappers kids don’t want to write
What about portability? You can move all of this to a new machine, completely reproducable, with zero additional permissions.
Thats living the dream, thats why I use containers for absolutely anything… Zero bloat, maximum portability.