[arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
Arch-wiki suggests: https://wiki.archlinux.org/index.php/System_maintenance#Install_the_linux-lt...
Tips and tricks The following tips are generally not required, but certain users may find them useful. Install the linux-lts package The linux-lts package is an alternative Arch kernel package, and is available in the core repository. This particular kernel version has long-term support (LTS) from upstream, including security fixes and some feature backports. It is useful if you prefer the stability of less-frequent kernel updates or if you want a fallback kernel in case a new kernel version causes problems.
and some guy told me
The LTS kernel is strictly speaking not in line with the "Arch philosophy" (if you use that term to describe the rolling release nature of Arch) - but it is also not a "typical" piece of software, for two reasons: It is the kernel, i.e. the core building block of what makes this operating system work. It is crucial to make sure it works correctly, so in case of an issue, having the possibility to go back to an LTS release (or forward to a non-LTS release) is in the interest of many users. It is mostly not affected by dependency issues arising from version mismatches (like soname bumps) - you can plug in any kernel you want without any major issues (except maybe hardware support). The second point also allows it to be packed in a rolling release distribution like Arch without causing trouble for maintainers. Maintaining an old user-space tool (i.e. backporting fixes, ensuring library version compatibility, ... well, see Debian) is incompatible with Arch Linux.
How hard or problematic to maintain a LTS package, for instance, KDE Plasma LTS edition package on Arch rolling-release-model? https://www.kde.org/announcements/plasma-5.8.0.php
Tuesday, 4 October 2016. Today KDE releases its first Long Term Support edition of its flagship desktop software, Plasma. This marks the point where the developers and designers are happy to recommend Plasma for the widest possible audience be they enterprise or non-techy home users.
What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
On Sat, 19 Nov 2016 02:34:08 +0900 Ken OKABE via arch-general <arch-general@archlinux.org> wrote:
What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
A whole lot more work for litte/no gain. The kernel is a different, as it can cause an unbootable situation.
On 11/18/2016 12:46 PM, Doug Newgard wrote:
On Sat, 19 Nov 2016 02:34:08 +0900 Ken OKABE via arch-general <arch-general@archlinux.org> wrote:
What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
A whole lot more work for litte/no gain. The kernel is a different, as it can cause an unbootable situation.
This. LTS releases are fundamentally in violation of the concept of "rolling release" -- we sort of want the latest everything! Sometimes, other concerns necessitate doing something that isn't strictly the Arch Way, however. The kernel is an excellent example -- as Doug said, if you cannot boot your computer there isn't a lot else you can do, it is time to pull out the installation media... For the firmware responsible for booting your computer and which is required even to get access to the emergency root shell, it is worth dealing with LTS. If something goes wrong with the latest plasma, okay, fine, you can revert the package update as a stopgap measure, debug plasma to submit bug reports and get it fixed, google workarounds... but your computer is not soft bricked (or hard bricked, but that is another matter entirely). Just like most LTS software, I do not see plasma-lts getting into the repos. However, the AUR exists in part to give such pet projects a home. Arch is ultimately whatever you make of it. But the [community] repo isn't the right place for personal experiments. -- Eli Schwartz
The kernel is a different, as it can cause an unbootable situation.
I can only imagine as follows: 1-a linux boot succesfully 1-b linux-lte boot succesfully 2 TYY or some DM load successfully 3-a Plasma might fail to launch 3-b Plasma-LTS might fail to launch On what reason or scenario, some LTS(maybe incompatible to the kernel) will break kernel or make the system unbootable? Regards, Ken On Sat, Nov 19, 2016 at 3:54 AM, Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
On 11/18/2016 12:46 PM, Doug Newgard wrote:
On Sat, 19 Nov 2016 02:34:08 +0900 Ken OKABE via arch-general <arch-general@archlinux.org> wrote:
What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
A whole lot more work for litte/no gain. The kernel is a different, as it can cause an unbootable situation.
This.
LTS releases are fundamentally in violation of the concept of "rolling release" -- we sort of want the latest everything!
Sometimes, other concerns necessitate doing something that isn't strictly the Arch Way, however. The kernel is an excellent example -- as Doug said, if you cannot boot your computer there isn't a lot else you can do, it is time to pull out the installation media...
For the firmware responsible for booting your computer and which is required even to get access to the emergency root shell, it is worth dealing with LTS. If something goes wrong with the latest plasma, okay, fine, you can revert the package update as a stopgap measure, debug plasma to submit bug reports and get it fixed, google workarounds... but your computer is not soft bricked (or hard bricked, but that is another matter entirely).
Just like most LTS software, I do not see plasma-lts getting into the repos. However, the AUR exists in part to give such pet projects a home. Arch is ultimately whatever you make of it. But the [community] repo isn't the right place for personal experiments.
-- Eli Schwartz
On Sat, Nov 19, 2016 at 08:31:22 +0900, Ken OKABE via arch-general wrote:
The kernel is a different, as it can cause an unbootable situation.
[...]
On what reason or scenario, some LTS(maybe incompatible to the kernel) will break kernel or make the system unbootable?
Ideally never. The unbootable situation may be caused by the *kernel itself*. I admit I'm a little amused about my forum post sparking a ML discussion, but to quote another post on that same thread (by Jason): https://en.wikipedia.org/wiki/Straw_man Best, Tinu a.k.a. ayekat
On Sat, 19 Nov 2016 03:27:43 +0900, Ken OKABE via arch-general wrote:
What's completely missing by the kernel related explanation is, that upstrem provides, IOW maintains longterm linux, https://www.kernel.org/ . Does KDE upstream maintain KDE Plasma LTS?
Ralf, exactly, and that is to what I'm attracted.
What happens if a shared library required by Plasma, is not part of the Plasma project? You either need to maintain the outdated lib or build against the new lib, which could cause issues for Plasma. I doubt it will work for a rolling release. Again, if it should work, a third party repository needs to provide it, since Arch is a real rolling release. On Fri, 18 Nov 2016 20:19:10 +0100, Bennett Piater wrote:
If it's still not stable enough for you, you might want to consider switching to something lighter, like XFCE or even a simple window manager (WM).
Xfce4 changed it's behaviour within a major release, just by upgrading to another dot release, apart from this Thunar is broken since a very long time, let alone that Xfce4 for sure doesn't provide what a bloated DE, such as KDE does provide and OTOH Xfce4 doesn't provide really more than a simple window manager provides. There is no way to provide a consistent and stable behaviour for a desktop environment within a rolling release. I dropped all desktop environments and after a while using jwm, I ended with using openbox. Unfortunately GTK3 and Qt5 are a PITA, qt5ct doesn't work for all apps and GTK3 has broken some apps completely. But even many GTK apps that aren't broken tend to ignore font configurations or depending on the used theme, font rendering differs among GTK apps. It's not better when using release model distros. In short, you carefully need to select apps. On Sat, 19 Nov 2016 08:31:22 +0900, Ken OKABE via arch-general wrote:
3-a Plasma might fail to launch 3-b Plasma-LTS might fail to launch
It's not the same as a kernel that doesn't work. The kernel is the direct interface to the hardware and provides basic functionality without an endless amount of interacting dependencies. It's easy to provide linux-lts. If the kernel should fail, you even can't repair the install. If Plasma fails, you could repair it from command line or by launching a window manager. Regards, Ralf
Le 18/11/2016 à 18:34, Ken OKABE via arch-general a écrit :
Arch-wiki suggests: https://wiki.archlinux.org/index.php/System_maintenance#Install_the_linux-lt...
Tips and tricks The following tips are generally not required, but certain users may find them useful. Install the linux-lts package The linux-lts package is an alternative Arch kernel package, and is available in the core repository. This particular kernel version has long-term support (LTS) from upstream, including security fixes and some feature backports. It is useful if you prefer the stability of less-frequent kernel updates or if you want a fallback kernel in case a new kernel version causes problems.
and some guy told me
The LTS kernel is strictly speaking not in line with the "Arch philosophy" (if you use that term to describe the rolling release nature of Arch) - but it is also not a "typical" piece of software, for two reasons: It is the kernel, i.e. the core building block of what makes this operating system work. It is crucial to make sure it works correctly, so in case of an issue, having the possibility to go back to an LTS release (or forward to a non-LTS release) is in the interest of many users. It is mostly not affected by dependency issues arising from version mismatches (like soname bumps) - you can plug in any kernel you want without any major issues (except maybe hardware support). The second point also allows it to be packed in a rolling release distribution like Arch without causing trouble for maintainers. Maintaining an old user-space tool (i.e. backporting fixes, ensuring library version compatibility, ... well, see Debian) is incompatible with Arch Linux. How hard or problematic to maintain a LTS package, for instance, KDE Plasma LTS edition package on Arch rolling-release-model?
https://www.kde.org/announcements/plasma-5.8.0.php
Tuesday, 4 October 2016. Today KDE releases its first Long Term Support edition of its flagship desktop software, Plasma. This marks the point where the developers and designers are happy to recommend Plasma for the widest possible audience be they enterprise or non-techy home users. What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
Well, first “affected by dependency issues arising from version mismatches (like soname bumps)”. So every time something that any plasma-lts package depends on require an ABI bump, you have to recompile things. You might say, devs have tools to do so quite automatically. Yes, but what if plasma-lts doesn’t build with the new libwhatever? Will plasma-lts have updates that take care of this? Will they be available ahead of libwhatever release? Then, consider the number of package plasma-lts represents. Multiply by their number of dependencies. Especially, kframeworks will continue moving ahead. Will compatibility with newer versions be assured? I’m not quite sure, since I don’t see why you would use lts plasma with latest frameworks. And that’s only one thing I can think of on the top of my head. So, lot of maintenance burden, for quite no gain. Bruno
Yes, but what if plasma-lts doesn’t build with the new libwhatever? Will
Then, consider the number of package plasma-lts represents. Multiply by
Bruno, plasma-lts have updates that take care of this? Will they be available ahead of libwhatever release? their number of dependencies. Especially, kframeworks will continue moving ahead. Will compatibility with newer versions be assured? I’m not quite sure, since I don’t see why you would use lts plasma with latest frameworks. I do not know the detail of how the dependency/libs of Plasma-LTS managed by the KDE developers, but, again, it is LTS. https://community.kde.org/Schedules/Plasma_5 According to their time schedule, they will release 5.8* LTS and 5.9.* simultaneously. I'm sure they will work properly for QT5 or wayland etc. compatibility issue and that is their problem, not Arch package maintainers. Please note I'm not saying multiple versions of DE co-existing system, but simply alternative LTS DE package. If there is another, LTS specific, old lib (QT5 or wayland whatever) needed, that is the lib Plasma-LTS depends on. Regards, Ken On Sat, Nov 19, 2016 at 2:49 AM, Bruno Pagani <bruno.pagani@ens-lyon.org> wrote:
Le 18/11/2016 à 18:34, Ken OKABE via arch-general a écrit :
Arch-wiki suggests: https://wiki.archlinux.org/index.php/System_maintenance#Install_the_linux-lt...
Tips and tricks The following tips are generally not required, but certain users may find them useful. Install the linux-lts package The linux-lts package is an alternative Arch kernel package, and is available in the core repository. This particular kernel version has long-term support (LTS) from upstream, including security fixes and some feature backports. It is useful if you prefer the stability of less-frequent kernel updates or if you want a fallback kernel in case a new kernel version causes problems.
and some guy told me
The LTS kernel is strictly speaking not in line with the "Arch philosophy" (if you use that term to describe the rolling release nature of Arch) - but it is also not a "typical" piece of software, for two reasons: It is the kernel, i.e. the core building block of what makes this operating system work. It is crucial to make sure it works correctly, so in case of an issue, having the possibility to go back to an LTS release (or forward to a non-LTS release) is in the interest of many users. It is mostly not affected by dependency issues arising from version mismatches (like soname bumps) - you can plug in any kernel you want without any major issues (except maybe hardware support). The second point also allows it to be packed in a rolling release distribution like Arch without causing trouble for maintainers. Maintaining an old user-space tool (i.e. backporting fixes, ensuring library version compatibility, ... well, see Debian) is incompatible with Arch Linux. How hard or problematic to maintain a LTS package, for instance, KDE Plasma LTS edition package on Arch rolling-release-model?
https://www.kde.org/announcements/plasma-5.8.0.php
Tuesday, 4 October 2016. Today KDE releases its first Long Term Support edition of its flagship desktop software, Plasma. This marks the point where the developers and designers are happy to recommend Plasma for the widest possible audience be they enterprise or non-techy home users. What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
Well, first “affected by dependency issues arising from version mismatches (like soname bumps)”. So every time something that any plasma-lts package depends on require an ABI bump, you have to recompile things. You might say, devs have tools to do so quite automatically. Yes, but what if plasma-lts doesn’t build with the new libwhatever? Will plasma-lts have updates that take care of this? Will they be available ahead of libwhatever release?
Then, consider the number of package plasma-lts represents. Multiply by their number of dependencies. Especially, kframeworks will continue moving ahead. Will compatibility with newer versions be assured? I’m not quite sure, since I don’t see why you would use lts plasma with latest frameworks.
And that’s only one thing I can think of on the top of my head.
So, lot of maintenance burden, for quite no gain.
Bruno
On Sat, 19 Nov 2016 02:34:08 +0900, Ken OKABE via arch-general wrote:
What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
Apart from the policy, the problem are maintainers willing it to do and to provide it by a third party repository. It's not that much work to provide it and all dependencies as separated packages, as long as you don't want e.g. security patches. IOW if you expect some quality, it's not just installing everything to /opt or providing it by something like snaps, you also need to maintain it, e.g. if there should be known vulnerabilities. What's completely missing by the kernel related explanation is, that upstrem provides, IOW maintains longterm linux, https://www.kernel.org/ . Does KDE upstream maintain KDE Plasma LTS? Regards, Ralf
What's completely missing by the kernel related explanation is, that upstrem provides, IOW maintains longterm linux, https://www.kernel.org/ . Does KDE upstream maintain KDE Plasma LTS?
Ralf, exactly, and that is to what I'm attracted. https://community.kde.org/Schedules/Plasma_5 According to the planned release schedule for Plasma 5, the 5.9.0, that is non-LTS will be released on 2017-01-31, but I simply want to stick to 5.8-LTS until the next Plasma-LTS release for the most concerned GUI stability of the system. In my experience, linux GUI environment(DE) tends to be easily broken with frequent upgrades, and I'm very happy to hear KDE project releases their first Long-Term-Support edition for Plasma. Regards, Ken On Sat, Nov 19, 2016 at 2:53 AM, Ralf Mardorf <silver.bullet@zoho.com> wrote:
On Sat, 19 Nov 2016 02:34:08 +0900, Ken OKABE via arch-general wrote:
What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?
Apart from the policy, the problem are maintainers willing it to do and to provide it by a third party repository. It's not that much work to provide it and all dependencies as separated packages, as long as you don't want e.g. security patches. IOW if you expect some quality, it's not just installing everything to /opt or providing it by something like snaps, you also need to maintain it, e.g. if there should be known vulnerabilities.
What's completely missing by the kernel related explanation is, that upstrem provides, IOW maintains longterm linux, https://www.kernel.org/ . Does KDE upstream maintain KDE Plasma LTS?
Regards, Ralf
Ralf, exactly, and that is to what I'm attracted.
That they maintain it doesn't necessarily mean that they will also make sure that it works with new library versions. It sounded more like bug- and security fixes to me. Arch is not like Debian or even Ubuntu. Most libraries get updated as soon as upstream releases new versions, which is quite often. I doubt the KDE developers will guarantee that the LTS version will work with every library upgrade. It's just too much work. The kernel is not only critical, but also much easier to manage - compared to something like Plasma, which depends on anything and everything, the kernel is for most intents and purposes a self-contained, interchangeable box. Userspace software is an entirely different category, and a huge DE like Plasma makes things even harder. Someone might try to maintain it on the AUR, but that could easily mean upwards of 50 packages that constantly need to be tested against new versions of their dependencies.
In my experience, linux GUI environment(DE) tends to be easily broken with frequent upgrades
Early Plasma versions where horrible, but its much better now. If it's still not stable enough for you, you might want to consider switching to something lighter, like XFCE or even a simple window manager (WM). I have a full Plasma installation to play around with, but my day-to-day use is entirely in i3wm. Properly set up, that beats even as good a DE as Plasma for me. If tiling is not your thing, there are other options out there, such as Openbox. (And maaaany more: [0]) Cheers, Bennett [0]: https://wiki.archlinux.org/index.php/Window_manager -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
participants (7)
-
Bennett Piater
-
Bruno Pagani
-
Doug Newgard
-
Eli Schwartz
-
Ken OKABE
-
Ralf Mardorf
-
Tinu Weber