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

Ken OKABE kenokabe at gmail.com
Fri Nov 18 19:03:58 UTC 2016


Bruno,

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

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


More information about the arch-general mailing list