Community really needs a KDE distro based on Archlinux

I think lately some hard work was done to add support for Fedora system upgrades in Discover, so why not for Archlinux.

I use zypper too for installing / updating too. For packages I just search online.

One downside of Tumbleeweed is that installing packages / updating takes forever compared to Arch.

Never say never :). That being said I agree. Hopefully AUR/Arch is the last thing Discover tries to support.

The Issue is that it works maybe now. But maybe it makes issues 1-2 years from now and then you don’t know how to fix it. That being said, I never tried Arch derivatives, maybe it works fine and I am just wrong.

That’s why you are supposed to do it the “hard way” first. That way you should know what to expect and deal with any issues yourself. If Discover fails to install AUR stuff or fails to update AUR stuff you will get a lot of angry bug reports why stuff doesn’t work.
The Arch Linux people can say RTFM, but KDE cannot.

1 Like

Just not a good match.

AUR is even not officially supported by Archlinux and Manjaro, and it was always user responsibility to use it. Most known apps are available on Arch repos and there is no need for AUR to be used. The real need is simply an official distro like KDE Neon but with latest upgrades for also non KDE apps.

2 Likes

I don’t really understand. Whats wrong with the Distros that ship KDE already? Is it just because of the package manager?

1 Like

Is it just because of the package manager

This is the major problem, Pamac was the hope, but it’s killed by some gnoomy fans, Octopi looks old and breaks too much.

But why not simply grab the latest apps as flatpaks or snaps on KDE neon?

2 Likes

Well, you have to take it up with the Manjaro folks. This is not the job of KDE to develop a GUI System Package Manager that would only work with Arch based distributions.

If a rolling release with a GUI package manager is all you want, then Tumbleweed with YAST is just what you are looking for.

Snaps are the most hated distributed apps because of that evil Canonical.
Flatpaks will grab huge files to install small apps which consumes huge disk space, and they suffer from slow performance and bad theming integration.

Because they want you to increase your workload ten-fold. Or hundred-fold?

2 Likes

I run Tumbleweed for the freshness of it, but I still chose to use the Flatpak version of LibreOffice. It is just simpler to let them handle all of those dependencies and not have to install those old versions of python packages into my system for no reason other than LibreOffice. It looks just fine with QT.

I run the Flatpak version of Discord, because it is way more stable and functional than the repo version. Why, I don’t know, but it works just fine.

Right, but you have to weigh those arguments against the preciously limited time of free software developers and packagers.
What’s worth more, the 1GiB occupied by a flatpak runtime or the >7 hours per week of an engineer doing a distro?

5 Likes

I understand why RedHat/Fedora moved from the Repo version of LibreOffice to the Flatpak version. The amount of time spent on maintaining that one huge program for every version of Redhat and Fedora that are still in support has to be a massive task. When I looked at that, I made the switch to test it and I will stick with the Flatpak.

I will most likely run very few Flatpaks, but for the few I do, I have no problems with them.

Way to conservative with that time estimate. All that user support + Bug reports would probably cost more time and you have not even solved the issue with maintaining the package manager.

€: @medin why not campaign for a qt fork of pamac instead? If that really is your only issue.

€2: or just use pacman and be happy :slight_smile:

1 Like

Well, first reason, in some countries like mine, people can’t afford to buy expensive laptops with big storage so each 1GB is really precious. And the second is the internet speed, even with that whole Manjaro stable upgrades that reach 2.5GB I found them supper heavy and takes too much time, and for people with discontinuous and limited internet it’s impossible to install those flatpaks.

why not campaign for a qt fork of pamac instead?

That Qt project was alive but was killed in favor of GTK framework.

I see where you are coming from, but Discover is a KDE package that has to run on multiple distros. It cannot be a System Package Manager. It is based on installing from a store and not from source packages. I can’t see how it could ever be such a thing.

Like @Duha said, take it up with the Manjaro folks and ask for a fork of Pamac that runs on KDE/QT. They are the ones that can make it happen.

1 Like

You can’t be the only person that runs KDE Plasma on Manjaro. Get on their forums and speak up about it. :grinning:

There is an old saying. “The squeaky wheel gets the grease.”

I appreciate that storage is relatively expensive depending on where one is, but still, you have to weigh that against the cost of engineering/labor. It remains 1 GiB of storage versus at least a day of work per week … forever. I am asking you to do the math on that. At face value I don’t see storage being even remotely as expensive as labor, regardless of where you are.

In the second part of your reply you appear to be making an argument against a rolling distro though, not sure what that is about :slight_smile:

1 Like

@medin Decent SSD drives are pretty cheap now. It’s an easy upgrade for the storage without a new laptop. I can’t help with your Internet speeds though.

you appear to be making an argument against a rolling distro though

In Manjaro, only unstable branch needs daily updates like Archlinux, but with stable branch we get the whole upgrades grouped late by 1 or 2 weeks, so it’s not hard to install them once in a month or more. For example, any major Plasma upgrade is always pushed into stable branch after it reaches the second or third maintenance cycle.