[arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?

[Bruno Pagani]

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-lts_package
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 492 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20161118/579cc733/attachment.asc>