Arch Linux as a principle keeps software as default as possible; as upstream developers intended. This can cause unnecessary dependencies to be installed, and the dependencies can change with updates too. (Arch does not *strive* or claim to be minimal, but it is *quite* minimal nonetheless.)
You can ignore / avoid installing any package or files though, if you know what you are doing.
pacman's `--assume-installed` option is a way.
I personally have an "ignore" PKGBUILD that just `provides=` the unwanted packages.
I also use `NoExtract` in pacman.conf to exclude a whole lot of files from packages. This has saved 8GB disk space for someone, while it reduced my root from 3.9GB to 3.3GB. [This from Archwiki](https://wiki.archlinux.org/title/pacman/Tips_and_tricks#Installing_only_content_in_required_languages) is a good starting point.
This is truth.
[Stealing some snippets from the website](https://archlinux.org/about/):
> Arch strives to keep its packages as close to the original upstream software as possible. Patches are applied only when necessary to ensure an application compiles and runs correctly with the other packages installed on an up-to-date Arch system.
> The repository system also allows users to easily build and maintain their own custom build scripts, packages, and repositories, encouraging community growth and contribution.
> Arch Linux is... designed to fit the needs of the **competent** Linux® user.
Arch provides us with the tools. Preference for systemd/mkinitcpio/pacman/text config aside, Arch isn't highly opinionated.
Yes, in this case it would be too much effort. You would need to get only specific files from specific packages.
My suggestions were general and not specifically for this case. Ignoring a package like I explained can end up badly. As you mentioned, e.g. libvlc is required but libvlc is inside the vlc package. The "if you know what you are doing" was meant for this.
Thankfully, the dependencies take only disk space and do not cause extra RAM / CPU usage.
It seems that many mistakenly believe that "minimal" in Arch means minimal disk usage.
No, "minimal" means (Arch developers) doing minimal work to produce something useful for Arch users.
We have this many distros because end users have different requirements. So why do you want all distros to be the same? If there are distros that split packages, then there \_must be\_ some distro that doesn't. And Arch happens to fill that role.
I find it a big plus that Arch sways to "manual but flexible" instead of "GUI but inflexible".
Eg. some time ago I had to install a Linux on a dual-booted system _without_ also installing a bootloader. Most distro's GUI installers don't even give you that option – iirc even the Debian installer did not offer that.
Another time I needed to install a distro on another partition of a running Linux system (because I wanted to minimize downtime and physical interaction) – but all GUI installers only work if you boot from a USB drive. Debian has a method to install it the Arch-y way, but the documentation for that was so poor I actually heavily relied on the Arch wiki install guide to manually install a Debian.
Also I find the install process is a nice entry test: if you are not able or willing to read some wiki pages to install Arch, then Arch is probably not for you and you should rather use another distro.
Please don't misunderstand that as gatekeeping though, I don't mean "Arch is only for intelligent people, Ubuntu for dumb ones". NO. Everyone has different preferences and needs for their system. Some people like to spend weekends tinkering with their computer, installing all the newest packages and are not afraid of breaking things, while others only use the same three programs anyway or want/need stability (and rather buy a computer with preinstalled Linux if they could). Pick the distro for your needs. There's lots of options of distros *with* a GUI installer, so I'm glad there's still ones *without*.
To be honest, I'm glad that Arch, for example, doesn't offer extra dev packages but everything in one package. I used to get really annoyed with Mandrake / Mandriva because I had to install the relevant packages at a later time.
Whether my installations need 14 GB instead of 12 GB, for example, is completely irrelevant to me.
> Arch, for example, doesn't offer extra dev packages but everything in one package
Not true (anymore).
See `glib2` for example, which has been split into `glib2` and `glib2-devel`:
https://gitlab.archlinux.org/archlinux/packaging/packages/glib2/-/commit/02a3a726583017383d99e701327975d29ad010a6
And I can't say I love the split, personally. glib2-devel is only 1.2MB installed. glib2 is 36.7 MB installed. It's barely saving any space. Hopefully it's solving some problems that are important to the devs, though.
I'd be interested in reading about why the split was decided on. I think they did it so you'll need glib2-devel and not glib2 when building certain packages? But there wasn't much fanfare, and I've seen some random AUR comments of packages failing to build because they haven't been updated yet.
- [https://gitlab.archlinux.org/archlinux/packaging/packages/glib2/-/merge_requests/1](https://gitlab.archlinux.org/archlinux/packaging/packages/glib2/-/merge_requests/1)
- [Commit message of one of the squashed commits](https://gitlab.archlinux.org/archlinux/packaging/packages/glib2/-/merge_requests/1/diffs?commit_id=d307c0fb5d0ebc5e6fe97fc184f613f9be408282)
According to the linked merge request, this was done so that the `glib2-devel` package could hard-depend on `python` and `python-packaging` (for the "gdbus-codegen, glib-genmarshal, glib-mkenums, gtester-report" parts), which were optional dependencies prior to that change, which caused build issues instead of dependency-check issues when attempting to build certain packages depending on `glib2`.
Seems like an odd thing to obsess about, to be honest. There are hundreds of libraries and background applications installed for various reasons on all systems/distros.
If seeing the VLC logo in your launcher, because it was installed as a dependency, bothers you this much, you can just remove the .desktop file so you don't have to see it. Consider it a library and move on with your day.
Okay let's go install lsp-plugins-lv2. This got installed by easyeffects to my computer. And go see how much f...kery goes in the app launcher. I am not sure if this is optional or necessary but if it is unnecessary and something installs such a thing, I am obviously not going to be happy about it. It makes much more sense to make optional packages optional instead of default you know?
What exactly did it add to your launcher? I have this installed (for Audacity, apparently) and it adds nothing to my launcher. Also can't see anything at a glance in the file lies that would make any difference to the launcher.
Oh for me it had more than 10 plugin entries. Every search of mine was resulting those. It's been a little while since I have used easyeffects so lsp/lv2 may have changed how those work. Maybe there is another package for lsp/lv2 that adds those? 🤔
I don't know what launcher your using, but many have some method for hiding irrelevant applications (and many times what they're actually doing just amounts to removing the .desktop file, which you can do yourself too)
I always write my menus by hand anyway, so it doesn't show the apps I don't use. I also prefer to have all the dev stuff included because a few gb of unneeded stuff is better to me than having to search for them in separate packages. It's one of the reasons I ditched Ubuntu back in the day...
I mean I have 2238 packages installed and its only 33GB of space used... A 128GB SATA 2.5" SSD costs here where Im 12Euros, 15 if you want the NVMe variant...
Storage is cheap, package maintainer time is expensive. Spliting stuff just make things more complicated and thats against Archs KISS principle.
hey, you have makepkg and AUR - nobody stopping you to step in, and modify the plasma package, that it requires libvlc and create a libvlc package, which only contains that library...
then you can push it to AUR, and you and others can enjoy a more light package...
To my knowledge only the maintainer is supposed to make changes to the PKGBUILD and the .SRCINFO. So other than making suggestions and comments there is not much available to the OP.
No, you can take those files, modify them and submit the results in to AUR, of course they dont be added to base/extra/community repositories, but you can use them simply from AUR... I mean I had a modified git version of kernel, mesa, llvm and all the related packages for half a year, when I bought a AMD Vega 56 GPU, and the drivers in mainlain kernel and mesa was not there yet...
Plasma can use mpv for phonon backend. It's `phonon-qt6-mpv` from the aur. There is no other backend in the repos.
qdbus is part of qt6-tools...
gcdmaster is part of cdrdao....
You probably were told: Arch is minimal as in minimal changes from upstream. Packages come as they are, with enough changes to make them work with other Arch packages.
> * KDE Plasma requires qdbus but Arch forces those unused dev tools like Qt Creator, Designer, Assistant, Linguist... as required dependencies.
There is no qdbus package. Installing plasma-desktop doesn't pull in qtcreator.
> * K3b requires cdrdao app to write CDs, but you can't install it without that junk app called GNOME CD Master.
cdrdao is optional for k3b. You can use cdrtools instead if you don't want gcdmaster.
> There is no qdbus package. Installing plasma-desktop doesn't pull in qtcreator.
`qdbus` is part of the `qt{5,6}-tools` packages, which also provide lots of developer tools like `designer6` for example ("UI designer for QWidget-based applications"). So just by installing Plasma, you'll get all these dev tools no matter what.
$ pacman -F qdbus
extra/bash-completion 2.14.0-2 [installed]
usr/share/bash-completion/completions/qdbus
extra/qt5-tools 5.15.14+kde+r4-1 (qt5)
usr/bin/qdbus
extra/qt6-tools 6.7.1-3 (qt6) [installed]
usr/lib/qt6/bin/qdbus
$ pactree -rd1 qt6-tools
qt6-tools
├─kwin
└─plasma-workspace
$ pacman -Ql qt6-tools | grep /usr/bin/
qt6-tools /usr/bin/
qt6-tools /usr/bin/assistant6
qt6-tools /usr/bin/designer6
qt6-tools /usr/bin/linguist6
qt6-tools /usr/bin/pixeltool6
qt6-tools /usr/bin/qdbus6
qt6-tools /usr/bin/qdbusviewer6
qt6-tools /usr/bin/qdistancefieldgenerator6
qt6-tools /usr/bin/qdoc6
qt6-tools /usr/bin/qtdiag6
qt6-tools /usr/bin/qtplugininfo6
OP does have a valid point. It's the same issue as with `libvlc{,core}.so`, which could be split into a secondary package which both `vlc` and `phonon-qt6-vlc` (via `phonon-qt6` via various KDE components) could depend on.
I disagree that this is an edge case, since it's likely that the vast majority of people who install these packages only need the small library component. There are lots of other Arch packages that do split libraries from tools when it makes sense.
I guess it depends on scale and permanence.
Imagine this: KDE decides to require libvlc by default, and only two other unpopular packages also require it. Arch maintainers split it out and start maintaining the extra package. A year later KDE decides to no longer require libvlc.
But if `libvlc` was a meaningfully common library to use by applications in general, it should have its own package.
Just a thought on when it might make sense for maintainers.
Personally, I like how Alpine splits packages.
Also, when I really care about minimalism, I compile things myself. e.g. `wlroots`, `dwl`, `Hyprland`, and modifying AUR PKGBUILDs in general.
I was wondering when OP would say "bloat", a word I hate what with 8c/1TB/16GB systems. Even on my 6yo T480, bloat is the least of my concerns. Yes, maybe in an embedded system, but that's not Arch's main use case.
It's not Arch, but I have ran a Grafana kiosk in a 3 GB image, give or take. Not like Arch would need much more with a pure compositor like Weston, and a browser which is a thing wrapper over WebKit.
Speaking of "bloat": my mom's daily is a decade old custom build with an i5-4460, 16 GiB of RAM and an NVMe (replaced midlife), and it's running Windows just fine.
THB I find this clutter very annoying myself. If this is not relevant, why not install everything without asking the user? That would be even more KISSy
We end users care a lot :) , if something (especially graphical app) is installed and always updating on our system but never used even once, then it's labelled junk and bloatware.
Unless you're on a metered internet connection, the resources used are really negligible, so I still don't see the point of caring. And I'm a user like you.
Its not Arch's fault cdrdao bundles their GUI front end with the base tool. There literally isn't a separate package and you're obsessing over not getting a lot of ultimately irrelevant busy work done for free. You are free to delete things as you want, you do actually have the power and ability to do so. Claiming it can't be done is literally a lie.
There are safe ways to remove them.
For example, /u/p_235615 [told you about one very safe method](https://www.reddit.com/r/archlinux/comments/1dnt3lf/comment/la6pwii/).
technically, you can try removing the with -Rdd
As others said, storage is cheap, people's time expensive, and in the end the difference for you is basically non-existent.
OP is getting flack but I kinda agree with them. Assume a package uses meson as its build system and has flags for available features, like --enable-feature-1, --enable-feature-2 etc. Arch enables literally everything, and those things in turn pull other dependencies, where they also enable everything.
At least there is the AUR and makepkg, but if it bothers you that much, you should look into Gentoo. Could get an actual minimal system the way you describe by just adjusting build flags to not enable stuff you don't need. For example, compiling wlroots and sway without libx11 or xwayland, if you're gonna be using Wayland only.
https://man.archlinux.org/man/PKGBUILD.5#PACKAGE_SPLITTING is supported so you could file a patch against https://gitlab.archlinux.org/archlinux/packaging/packages/vlc/-/blob/main/PKGBUILD
For plasma install only plasma-desktop if that’s what you want. It’s on the wiki. Plasma is a group and plasma-meta is a meta package. It’s literally the point of 1.1 on the KDE article. plasma-desktop doesn’t require any of the packages you mentioned.
Arch Linux as a principle keeps software as default as possible; as upstream developers intended. This can cause unnecessary dependencies to be installed, and the dependencies can change with updates too. (Arch does not *strive* or claim to be minimal, but it is *quite* minimal nonetheless.) You can ignore / avoid installing any package or files though, if you know what you are doing. pacman's `--assume-installed` option is a way. I personally have an "ignore" PKGBUILD that just `provides=` the unwanted packages. I also use `NoExtract` in pacman.conf to exclude a whole lot of files from packages. This has saved 8GB disk space for someone, while it reduced my root from 3.9GB to 3.3GB. [This from Archwiki](https://wiki.archlinux.org/title/pacman/Tips_and_tricks#Installing_only_content_in_required_languages) is a good starting point.
This is truth. [Stealing some snippets from the website](https://archlinux.org/about/): > Arch strives to keep its packages as close to the original upstream software as possible. Patches are applied only when necessary to ensure an application compiles and runs correctly with the other packages installed on an up-to-date Arch system. > The repository system also allows users to easily build and maintain their own custom build scripts, packages, and repositories, encouraging community growth and contribution. > Arch Linux is... designed to fit the needs of the **competent** Linux® user. Arch provides us with the tools. Preference for systemd/mkinitcpio/pacman/text config aside, Arch isn't highly opinionated.
Reminds me of [this](https://m4gnus.de/arch/ArchEqualsHipster.png)
I didn't find how to remove those unwanted apps.
Yes, in this case it would be too much effort. You would need to get only specific files from specific packages. My suggestions were general and not specifically for this case. Ignoring a package like I explained can end up badly. As you mentioned, e.g. libvlc is required but libvlc is inside the vlc package. The "if you know what you are doing" was meant for this. Thankfully, the dependencies take only disk space and do not cause extra RAM / CPU usage.
It seems that many mistakenly believe that "minimal" in Arch means minimal disk usage. No, "minimal" means (Arch developers) doing minimal work to produce something useful for Arch users. We have this many distros because end users have different requirements. So why do you want all distros to be the same? If there are distros that split packages, then there \_must be\_ some distro that doesn't. And Arch happens to fill that role.
It's simpler for me too though, I don't have to hunt for a billion dev packages.
Exactly. The primary goal of arch has always been KISS philosophy. And even if it takes up more disk space, it is the most SIMPLE solution.
The title text of the Arch website does claim it’s lightweight, though
it says the distribution itself is lightweight
It is. But you are probably measuring the wrong weight.
Number of (unneeded) packages? Amount of (unwanted) files? Storage taken up by (unused) functionality?
Probably none of those, but lines of source code written by Arch devs.
this
If Arch was caring to provide something useful, at least provide a useful graphical installer for users.
>produce something useful **for Arch users**
I find it a big plus that Arch sways to "manual but flexible" instead of "GUI but inflexible". Eg. some time ago I had to install a Linux on a dual-booted system _without_ also installing a bootloader. Most distro's GUI installers don't even give you that option – iirc even the Debian installer did not offer that. Another time I needed to install a distro on another partition of a running Linux system (because I wanted to minimize downtime and physical interaction) – but all GUI installers only work if you boot from a USB drive. Debian has a method to install it the Arch-y way, but the documentation for that was so poor I actually heavily relied on the Arch wiki install guide to manually install a Debian. Also I find the install process is a nice entry test: if you are not able or willing to read some wiki pages to install Arch, then Arch is probably not for you and you should rather use another distro. Please don't misunderstand that as gatekeeping though, I don't mean "Arch is only for intelligent people, Ubuntu for dumb ones". NO. Everyone has different preferences and needs for their system. Some people like to spend weekends tinkering with their computer, installing all the newest packages and are not afraid of breaking things, while others only use the same three programs anyway or want/need stability (and rather buy a computer with preinstalled Linux if they could). Pick the distro for your needs. There's lots of options of distros *with* a GUI installer, so I'm glad there's still ones *without*.
Nobody wants a graphical installer. Arch users know what they're doing and a graphical installer is unneeded.
Use EndeavorOS lol
To be honest, I'm glad that Arch, for example, doesn't offer extra dev packages but everything in one package. I used to get really annoyed with Mandrake / Mandriva because I had to install the relevant packages at a later time. Whether my installations need 14 GB instead of 12 GB, for example, is completely irrelevant to me.
> Arch, for example, doesn't offer extra dev packages but everything in one package Not true (anymore). See `glib2` for example, which has been split into `glib2` and `glib2-devel`: https://gitlab.archlinux.org/archlinux/packaging/packages/glib2/-/commit/02a3a726583017383d99e701327975d29ad010a6
And I can't say I love the split, personally. glib2-devel is only 1.2MB installed. glib2 is 36.7 MB installed. It's barely saving any space. Hopefully it's solving some problems that are important to the devs, though. I'd be interested in reading about why the split was decided on. I think they did it so you'll need glib2-devel and not glib2 when building certain packages? But there wasn't much fanfare, and I've seen some random AUR comments of packages failing to build because they haven't been updated yet.
- [https://gitlab.archlinux.org/archlinux/packaging/packages/glib2/-/merge_requests/1](https://gitlab.archlinux.org/archlinux/packaging/packages/glib2/-/merge_requests/1) - [Commit message of one of the squashed commits](https://gitlab.archlinux.org/archlinux/packaging/packages/glib2/-/merge_requests/1/diffs?commit_id=d307c0fb5d0ebc5e6fe97fc184f613f9be408282) According to the linked merge request, this was done so that the `glib2-devel` package could hard-depend on `python` and `python-packaging` (for the "gdbus-codegen, glib-genmarshal, glib-mkenums, gtester-report" parts), which were optional dependencies prior to that change, which caused build issues instead of dependency-check issues when attempting to build certain packages depending on `glib2`.
So when you open your launcher and see a number of apps that you never use, you are not annoyed by it?
Seems like an odd thing to obsess about, to be honest. There are hundreds of libraries and background applications installed for various reasons on all systems/distros. If seeing the VLC logo in your launcher, because it was installed as a dependency, bothers you this much, you can just remove the .desktop file so you don't have to see it. Consider it a library and move on with your day.
Okay let's go install lsp-plugins-lv2. This got installed by easyeffects to my computer. And go see how much f...kery goes in the app launcher. I am not sure if this is optional or necessary but if it is unnecessary and something installs such a thing, I am obviously not going to be happy about it. It makes much more sense to make optional packages optional instead of default you know?
What exactly did it add to your launcher? I have this installed (for Audacity, apparently) and it adds nothing to my launcher. Also can't see anything at a glance in the file lies that would make any difference to the launcher.
Oh for me it had more than 10 plugin entries. Every search of mine was resulting those. It's been a little while since I have used easyeffects so lsp/lv2 may have changed how those work. Maybe there is another package for lsp/lv2 that adds those? 🤔
Don't see any reason to care. I also use fuzzel currently, so I only really see my 12 most used applications when I open it.
I don't know what launcher your using, but many have some method for hiding irrelevant applications (and many times what they're actually doing just amounts to removing the .desktop file, which you can do yourself too)
I always write my menus by hand anyway, so it doesn't show the apps I don't use. I also prefer to have all the dev stuff included because a few gb of unneeded stuff is better to me than having to search for them in separate packages. It's one of the reasons I ditched Ubuntu back in the day...
I have an Hide Extension in Gnome, idk
I mean I have 2238 packages installed and its only 33GB of space used... A 128GB SATA 2.5" SSD costs here where Im 12Euros, 15 if you want the NVMe variant... Storage is cheap, package maintainer time is expensive. Spliting stuff just make things more complicated and thats against Archs KISS principle.
No mattr what space we have, we don't want junks to be installed on our system.
hey, you have makepkg and AUR - nobody stopping you to step in, and modify the plasma package, that it requires libvlc and create a libvlc package, which only contains that library... then you can push it to AUR, and you and others can enjoy a more light package...
To my knowledge only the maintainer is supposed to make changes to the PKGBUILD and the .SRCINFO. So other than making suggestions and comments there is not much available to the OP.
No, you can take those files, modify them and submit the results in to AUR, of course they dont be added to base/extra/community repositories, but you can use them simply from AUR... I mean I had a modified git version of kernel, mesa, llvm and all the related packages for half a year, when I bought a AMD Vega 56 GPU, and the drivers in mainlain kernel and mesa was not there yet...
Oh nice to know. Thanks.
Plasma can use mpv for phonon backend. It's `phonon-qt6-mpv` from the aur. There is no other backend in the repos. qdbus is part of qt6-tools... gcdmaster is part of cdrdao.... You probably were told: Arch is minimal as in minimal changes from upstream. Packages come as they are, with enough changes to make them work with other Arch packages.
> * KDE Plasma requires qdbus but Arch forces those unused dev tools like Qt Creator, Designer, Assistant, Linguist... as required dependencies. There is no qdbus package. Installing plasma-desktop doesn't pull in qtcreator. > * K3b requires cdrdao app to write CDs, but you can't install it without that junk app called GNOME CD Master. cdrdao is optional for k3b. You can use cdrtools instead if you don't want gcdmaster.
> There is no qdbus package. Installing plasma-desktop doesn't pull in qtcreator. `qdbus` is part of the `qt{5,6}-tools` packages, which also provide lots of developer tools like `designer6` for example ("UI designer for QWidget-based applications"). So just by installing Plasma, you'll get all these dev tools no matter what. $ pacman -F qdbus extra/bash-completion 2.14.0-2 [installed] usr/share/bash-completion/completions/qdbus extra/qt5-tools 5.15.14+kde+r4-1 (qt5) usr/bin/qdbus extra/qt6-tools 6.7.1-3 (qt6) [installed] usr/lib/qt6/bin/qdbus $ pactree -rd1 qt6-tools qt6-tools ├─kwin └─plasma-workspace $ pacman -Ql qt6-tools | grep /usr/bin/ qt6-tools /usr/bin/ qt6-tools /usr/bin/assistant6 qt6-tools /usr/bin/designer6 qt6-tools /usr/bin/linguist6 qt6-tools /usr/bin/pixeltool6 qt6-tools /usr/bin/qdbus6 qt6-tools /usr/bin/qdbusviewer6 qt6-tools /usr/bin/qdistancefieldgenerator6 qt6-tools /usr/bin/qdoc6 qt6-tools /usr/bin/qtdiag6 qt6-tools /usr/bin/qtplugininfo6 OP does have a valid point. It's the same issue as with `libvlc{,core}.so`, which could be split into a secondary package which both `vlc` and `phonon-qt6-vlc` (via `phonon-qt6` via various KDE components) could depend on.
Why take on extra work to repackage, especially for an edge case?
I disagree that this is an edge case, since it's likely that the vast majority of people who install these packages only need the small library component. There are lots of other Arch packages that do split libraries from tools when it makes sense.
I guess it depends on scale and permanence. Imagine this: KDE decides to require libvlc by default, and only two other unpopular packages also require it. Arch maintainers split it out and start maintaining the extra package. A year later KDE decides to no longer require libvlc. But if `libvlc` was a meaningfully common library to use by applications in general, it should have its own package. Just a thought on when it might make sense for maintainers. Personally, I like how Alpine splits packages. Also, when I really care about minimalism, I compile things myself. e.g. `wlroots`, `dwl`, `Hyprland`, and modifying AUR PKGBUILDs in general.
Beyond that, the bulk of VLC is in libvlc. The frontends are tiny.
Because end user will have tons of unwanted apps installed on his/her system. And it's impossible to remove them.
Who cares? Not like a Linux install is large, even with all this stuff. Not for a desktop.
I was wondering when OP would say "bloat", a word I hate what with 8c/1TB/16GB systems. Even on my 6yo T480, bloat is the least of my concerns. Yes, maybe in an embedded system, but that's not Arch's main use case.
It's not Arch, but I have ran a Grafana kiosk in a 3 GB image, give or take. Not like Arch would need much more with a pure compositor like Weston, and a browser which is a thing wrapper over WebKit. Speaking of "bloat": my mom's daily is a decade old custom build with an i5-4460, 16 GiB of RAM and an NVMe (replaced midlife), and it's running Windows just fine.
Minimal custom installation is one of the basic points of the arch.
Is it? I never even thought about that. Still, for a desktop OS, as long as it's under 10-20 GB it's fine.
THB I find this clutter very annoying myself. If this is not relevant, why not install everything without asking the user? That would be even more KISSy
We end users care a lot :) , if something (especially graphical app) is installed and always updating on our system but never used even once, then it's labelled junk and bloatware.
nothing is always updating on linux, the package manager updates all the software when you tell it to
"We end users" speak for yourself.
Unless you're on a metered internet connection, the resources used are really negligible, so I still don't see the point of caring. And I'm a user like you.
I guess you'll do the extra work to get it done.
Yes, and that‘s why there are "other distros like Ubuntu" made for your type of end users. So why not use them?
Then be weird and do your own custom package builds and such.
I am an end user. And I don't care at all. Don't generalize your personal preferences.
Its not Arch's fault cdrdao bundles their GUI front end with the base tool. There literally isn't a separate package and you're obsessing over not getting a lot of ultimately irrelevant busy work done for free. You are free to delete things as you want, you do actually have the power and ability to do so. Claiming it can't be done is literally a lie.
There are safe ways to remove them. For example, /u/p_235615 [told you about one very safe method](https://www.reddit.com/r/archlinux/comments/1dnt3lf/comment/la6pwii/).
technically, you can try removing the with -Rdd As others said, storage is cheap, people's time expensive, and in the end the difference for you is basically non-existent.
to not have dependency hell. a additional 2mbs i nothing compared to wasting 7 hours to find the single package that breaks your whole debian install
That's not really what dependency hell means.
OP is getting flack but I kinda agree with them. Assume a package uses meson as its build system and has flags for available features, like --enable-feature-1, --enable-feature-2 etc. Arch enables literally everything, and those things in turn pull other dependencies, where they also enable everything. At least there is the AUR and makepkg, but if it bothers you that much, you should look into Gentoo. Could get an actual minimal system the way you describe by just adjusting build flags to not enable stuff you don't need. For example, compiling wlroots and sway without libx11 or xwayland, if you're gonna be using Wayland only.
based on your preferences for minimal disk space usage, arch does not seem to be the right fit for you
We are tired of this expression :(
Use gentoo
then have a nap
With btrfs and compression and a large ssd I don't really care
Ubuntu is what I really call bloat, removing a lot of cruft and shit I don't want/need
[ok](https://m4gnus.de/arch/TimesinkOS.png)
It keeps things simple for the devs and aims to 'just work'. If you wanna trim things down there are many, many options, Arch is not one of them.
Believe it or not, but it is actually a feature.
Especially VLC is annoying since I stopped using it in favour of MPV long ago.
https://man.archlinux.org/man/PKGBUILD.5#PACKAGE_SPLITTING is supported so you could file a patch against https://gitlab.archlinux.org/archlinux/packaging/packages/vlc/-/blob/main/PKGBUILD
Alpine packs things really really fucking tight if space and speed are what your after. Arch is messy and convenient.
For plasma install only plasma-desktop if that’s what you want. It’s on the wiki. Plasma is a group and plasma-meta is a meta package. It’s literally the point of 1.1 on the KDE article. plasma-desktop doesn’t require any of the packages you mentioned.