Tried again and it’s still missing stuff. Not sure what other couple of packages you installed? There was no display adjustment in settings.
Holy crap there’s a lot of activity since I left. Apologies for any inconvenience I may have caused you lot! I wish to clarify my stance about Bluedevil being included, since I see some people are kind of against the decision to resolve the problem like that —
The movement away from the headphone jack and inculcating the idea of using wireless peripherals into the masses certainly has created an increase in demand for wireless Bluetooth peripherals, and while I sincerely understand the security concerns presented by using Bluetooth, as many other people would I tend not to care about that because I have no particular security challenges to overcome.
If we are going to expect more people pick up Linux and make open source a significant part of their life over the gong-show that’s become Microsoft Windows, then all of the options need to be available. Within Windows, you can’t necessarily rip out certain aspects like Bluetooth without uninstalling drivers and blacklisting them, at least in Linux land, Arch more specifically we have this option to disable Bluetooth beyond just turning it off by disabling and stopping its service as well choosing to not enable it at-boot. Considering some of the forum moderators had already said Bluedevil’s exclusion was a mistake there’s really no reason to complain about it since you can always just sudo pacman -R it.
Arguably, one could also say Windows has services via
services.mscwhere Bluetoooth could be disabled permanently there but hot too many people are aware of it, even with task manager showing services since Windows 10.
Even better if this was its own separate package, you just disallow installing it forthright using Calamares, so it’s literally one less thing to remove. But I am under this impression as big tech wants users to move toward a wireless future, we act in lock-step if we want to provide the least inconvenient out-of-the-box experience we can. Again if there is disdain you wish to express, just fix it by removing all of the Bluetooth crap. Nobody said you needed to have it, nor did anyone say it’s necessary, and it’s your computer — we can’t, nor would want to stop you.
1 Like
The secret recipe
Add a pinch of kscreen and see if you cans spice it up 
Nevertheless, what I ended up with is still very minimal yet, no dolphin, no kate, no any k-stuff.
Very KISS.
First of all, let us welcome you to EnOS’ forum!
We are glad that you have chosen EndeavourOS and we look forward and appreciate your suggestions and contributions for betterment of the system we all love and for enriching our community.
Some of us might have a peculiar sense of humor sometimes that might not be recognized at a first glance for someone new to the forum. What I see is no disdain expressed towards a piece of software or the use of it. Some might have expressed their dislike and some might have tried to bring clarity as to what was actually included in the pkglist to be installed, if it was omission or by design.
This is magnanimous of you and whoever else the “we” includes. Quite rare attitude in this time and age towards others with divergent opinions and/or practices than yours. We are highly appreciative of it.
Enjoy your adventure onboard Endeavour!
And have a great weekend!
To end this long story …
From EndeavourOS development point we do not want to set up anything running per default someone may or may not need/want/use.
The phrase “as close to arch as possible” says that we try to stay with the defaults shipped with the packages from arch repositories on the one hand but create a basic working system to start with on the other hand.
Where archlinux packages groups or meta-package swill pull in everything possible to the DE installs we slim these packages groups down to a minimal install to start with.
In the case of systemd services it is a bad design on the side of the DE development to not include a way to handle them this is nothing we choose to do or arch is doing. (Someone could disagree and teach me otherwise? gladly 
) So you can go using one of the badly designed GUI apps to handle systemd which is more complicated than using the terminal and learning a few commands.
And about Bluetooth and plasma … yes it is convenient and the default way to handle it with bluedevil integrated into the settings GUI… but:
You do not have to use it. It is just working with some simple commands from terminal 
This will let you reach some better knowledge about how exactly the process is working …
But indeed your PC is personal again with Linux and even more using archbase 
5 Likes
After my initial post, I started poking around in the various KDE VMs I have of other distros. I have learned two things.
First, the other distros are just installing bluedevil (KDE). So as pointed out in a few posts above, there is software not needed/used. I am not insinuating this is the right way, just the path they chose.
Second, as I noted this may just be my device. This is the case, as my device is capable of two devices being connected at the same time. The bluedevil software is able to trigger a secondary device ID and connect correctly, while my bluetoothctl knowledge is deficient and cannot make it trigger this. If I had read the wiki page all the way through the first time, instead of jumping to bluetoothctl instructions, I probably would not have discovered this deficiency and had it working in 10 minutes instead of 30 minutes.
After reading the views above, and my new knowledge, I think now I would say that EndeavourOS is doing just fine with the decision that they have chosen.
BFD. Just…
pacman -Rns plasma-meta
pacman -S plasma
Since plasma and plasma-meta have the same package list it would be a lot less destructive to simply sudo pacman -R plasma-meta and then mark it’s dependencies as explicitly installed.
3 Likes
It might be, but offered no problems doing as I did subsequent to using archinstall. It is a python script and the archinstall.profile can be altered to accommodate changes beforehand, which is what I should have done.
It depends on when you did it and how all the packages were installed. If the X11 packages were pulled in as dependencies of plasma-meta it would either remove all your GUI applications or just fail to run.
If you did it immediately following a minimal install that had no applications it might not be a huge deal.
Either way, I would say it is not generally the best approach to switching from plasma-meta to plasma.
2 Likes
Probably not; I just seem lucky that way. Plasma doesn’t have the same dependencies as plasma-meta, and is more easily malleable.
EDIT: pacman -Rsu might have also been used instead of -Rns
Cool script: https://gist.github.com/frap129/52aecac6e82194e8a8953dd756a0bf03
So does installing plasma vs plasma-meta remove the packages from being a dependency?
Yes, it is the difference between a group and meta-package.
A group installs packages by installing a list of packages explicitly. The advantage of this approach is that individual packages can be removed or not installed in the first place. The disadvantage is that when new packages are added or removed from the group, that won’t have any impact on a running system.
A meta-package installs packages by adding them as dependency of an empty package. The advantage here is that when packages are added to the meta package they will automatically be added to your system. The disadvantage is that there is no reliable way to remove any components of the meta-package so you are stuck with all of them.
The Arch wiki has a more detailed explanation here:
https://wiki.archlinux.org/title/Meta_package_and_package_group
4 Likes
@dalto has already replied to your post but this is a nice post that I have bookmarked regarding converting the dependencies of a metapackage to explicitly installed:
3 Likes
This is why I like hanging out on this forum…I have probably learned more in the past few months than I have in the 15 years or so I have been using Linux about how things work.
3 Likes
@dalto
The following command is from one of your posts (linked above) on dealing with removal of a meta package and converting its dependencies to explicitly installed:
- Convert the individual packages to explicitly installed
sudo pacman -D --asexplicit $(expac -S '%D' kde-utilities-meta)
Now adapting it to the plasma-meta situation, since the packages in plasma group can be listed with:
pacman -Sg plasma
could the expac part be replaced by something like the following:
sudo pacman -D --asexplicit $(pacman -Sg plasma)
1 Like
Two things:
- You would want to use
-Sgqto only have the package names - That would work, but it counts on
plasmahaving the same packages asplasma-metawhich, in theory, it should. The example I gave instead pulls the package list from the meta package.
2 Likes
Thanks for the reply and the explanation!
I was a bit slow to realize it before posting! I did right after 
Sure, I understand that this is the better approach to make sure that only the packages in the meta-package are listed, no more, no less.
Thanks!
1 Like
so in review sudo pacman -D --asexplicit $(expac -S '%D' plasma-meta) will mark them as explicit
and sudo pacman -D --asexplicit $(pacman -Sgq plasma) will convert them from being in the meta to a group?
I ran both in VMs and they both at least for me had the desired outcome of not making everything in the plasma-meta into a bunch of orphans, but option B didn’t require installing an extra package to perform.
No, both commands basically do the exact same thing(Mark the packages as explicitly installed). They just get the list of packages differently.
You can’t convert something to a group. A group is just some additional data tied to the package that is convenient way to list or install them.
2 Likes