What would the Manjaro Community dream about KDE?

kde

#102

Phil, how about we use the “normal” KDE applications in Unstable and later on in Testing, change them when new ones arrive (like a true rolling distro) and when there is a time things are stable they can be moved over to Manjaro Stable and become a new LTS in there.
It would mean that in Unstable and Testing you never have an LTS versions, while in Stable you only have an LTS version of the KDE software. It’s one way or another.
Updates will be further apart, giving more rest for the people who need a stable release, who don’t care much about the latest and greatest, who use a computer to get things done.


#103

See my other post above.
You are also confusing frameworks and the KDE applications suite with Plasma 5 itself. ONLY plasma 5 (plasma-desktop) is LTS, not the other two.


#104

I can’t understand the so much confusion.
We are talking about packages, not branches or mirrors.
We already have FF-dev in parallel on the same branch.
Plasma 5.13 is a development version as the devs work it out.
LTS has nothing to do with stability, just support, even if it may be more stable.


#105

I’m sure the smart people from upstream will find the best solution. Assume that it will work. The question is what the end users will prefer to have: Plasma LTS or the latest and the greatest?


#106

Firefox-KDE would be nice


#107

Latest.
If the work isnt too much, then I’m all for having the LTS option available for whomever wants it.
But only as an option - I thought thats what we were talking about.
If it were an X or Y thing… then that would turn my “nope” factor all the way up.


#108

I don’t think so that the majority will prefer the latest vs. LTS.


#109

I agree with this 100%. I was under the impression that we were discussing adding KDE-LTS as an option, not replacing what we have today.

That being said, if you mean what should be used by default on the iso, I don’t think it matters much as long as both are available.


#110

Let me take that one step further and also ask to add in the ubuntu (unity patch set) for global menus as well, if possible. However, I think that that was the coveat, the plasma patches and ubuntu pacthes were incompatable with one another, I’ll need to do some more research. :wink:


#111

Me too. YaST was/is wonderful.


#112

there is already one… :slight_smile:

https://forum.manjaro.org/t/firefox-firefox-kde-repository


#113

True, but for a few releases Arch itself seems to wait bit until GNOME/GTK FUpdtes reaches arch stable, while for KDE and Qt, for some reason, it will just go to stable, even if it is not.

It’s up to you to update, so thats not a issue. Just wait for yourself. But in general it would be nice to have something constant in this direction. 2 weeks also seems to be a fair time to test, while not to long to wait on a rolling release.


#114

Maybe that seems reasonable for someone that doesn’t do this sort of thing for a living.
However, take it from someone that does do system building, network and software integration, as well as software packaging and testing for a living, two weeks on many, many things is not even close to reasonable.


#115

Depending on the amount of effort needed, a separate kde-lts repo might be an option. IIRC this can be added to a pacman.conf ahead of the standard repos so would be prioritised ahead of the mainline releases.

Otherwise, it would need a separate set of -lts packages which would conflict with the standard packages but could then be installable with a kde-lts group.


#116

As someone that works closely with the KDE group, it’s not all of KDE that is LTS, it’s only Plasma itself.
This only includes the packages for the DE, it does not include frameworks, or any of the KDE applicataions suite (dolphin, kate, konsole, kmail, kamoso, etc.)

$ sudo pacman -Sg plasma
plasma bluedevil
plasma breeze
plasma breeze-gtk
plasma discover
plasma drkonqi
plasma kactivitymanagerd
plasma kde-cli-tools
plasma kde-gtk-config
plasma kdecoration
plasma kdeplasma-addons
plasma kgamma5
plasma khotkeys
plasma kinfocenter
plasma kmenuedit
plasma knetattach
plasma kscreen
plasma kscreenlocker
plasma ksshaskpass
plasma ksysguard
plasma kwallet-pam
plasma kwayland-integration
plasma kwin
plasma kwrited
plasma libkscreen
plasma libksysguard
plasma milou
plasma oxygen
plasma plasma-browser-integration
plasma plasma-desktop
plasma plasma-gpg-agent
plasma plasma-integration
plasma plasma-nm
plasma plasma-pa
plasma plasma-sdk
plasma plasma-ssh-agent
plasma plasma-vault
plasma plasma-workspace
plasma plasma-workspace-wallpapers
plasma polkit-kde-agent
plasma powerdevil
plasma sddm-kcm
plasma systemsettings
plasma user-manager
plasma xdg-desktop-portal-kde

#117

Yeah so making a separate plasma-lts group would not be a problem if people do really need this.


#118

Nope, not realy…

People are just still stuck in the old KDE4 way of thinking that all of KDE is one thing, when in reality it never was. The KDE release team just released everything together at the same time, but that proved to be problemetic.

Here is how it actually breaks down:
A: The KDE frameworks 5 (prev. kdelibs 4) that are built on top of and add extra functionality to Qt.

B: The Plasma desktop itself, plasma 1,2,3, 4 and now 5.

C: And finally, the suite of officially supported and complimentory applications (like dolphin, kate, konsole, etc.) that are not part of the desktop itself, and are in reality, just a collection of seperate applications.


#120

I second this strongly!!! Discover is the most disgusting, unstable and malfunctioning piece of KDE! If I have to beg you NOT to incorporate Discover, I do it hereby!!! Discover never!!!


#121

We’ve been shipping Discover on Netrunner Rolling for aprox. 2 years now.
We haven’t really had many issues stemming from it directly, most issues were with the packagekit alpm backend and/or appstream, but most, if not all of those have been addressed already. Keep in mind that gnome software also uses both of these, as well as to some extent pamac uses appstream as well.

Well, to each his own I guess.


#122

+1 for this!

What i also thought about is: Why not also include the wayland session (inactive by default), since plasma should be at a point where you can alsready use it, if you want and it seems to be not to heavy on dependencies. :thinking: