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
signature.asc
Description: OpenPGP digital signature
