LMS purification -- LMS EOL on Synology

[jvromans@squirrel.nl]

One of these days Synology will update the Perl package on DSM from
version 5.24 to 5.28. DSM 7.0 will ship with 5.28.

Currently there is an old LMS package for Synology that is based on Perl
5.24 (for native libraries) and of which the pure Perl modules for LMS have
been upgraded to LMS 8.0. After the upcoming Perl upgrade this package will
no longer run due to mismatch in the native libraries.

Apparently noone is able/capable/willing to upgrade and rebuild LMS for
Synology so this is the end. Personal feelings[1] aside, this is a pity.

Building LMS involves building a vast collection of special versions of
libraries and modules, sometimes custom patched. A couple of times there
have been attempts to create builds of LMS using only officially supported
(and distributed) versions of libraries and modules but as far as I know
they were not successful.

Even though I can personally live with the current situation, I think it
would be beneficial to purify the LMS build and packaging. The less
dependencies the better.

What do you think?

-- Johan

Footnote 1: Personally I don't care much for Synology. I moved LMS to a RPi3
a long time ago (now: RPi4 with SSD) with much better results -- and
support.

[gordonb3]

I run LMS on a platform that has not been supported since Perl 5.12, which was fine when it still ran Debian Squeeze but not with any more recent Linux. I have in fact been supporting this installation for other users that moved to Gentoo Linux on this platform, starting with Perl 5.20 and currently Perl 5.30.

Thus having some experience on this subject, I found the main issue with LMS being that it includes way to many CPAN modules that may work with one version of Perl, or maybe several versions of Perl, but not all and yet most of them are marked as version independent (i.e. not in the `arch` subtree). So in the dependency listing for my package I have around 20 CPAN modules listed, but the number installed is in fact closer to 80, each introducing their own possible version conflict because LMS prefers its own installation tree while trying to find these modules, but Perl's DynaLoader which is needed for loading the arch dependant libraries prefers the system path that is also used by other installed Perl consumers.

Typical errors you'll see as a result is that `DynaLoader failed to load module ...`, which is about the most descriptive Perl gets because if it can't find a minimal or even specific version for a module it will simply state that it can't find the module at all. A possible solution to this would be to run LMS in an isolated container, but this is not an option for my hardware platform. The way I resolve the conflicts is to remove (most of ¹) the duplicate files in which I make the system the leading party. Pretty sure this should work on Synology and other `smart` NAS systems as well.



¹ Slimserver apparently defines a strict dependency on DBIx module versions and therefore these need to be kept inside the LMS tree. As far as I can see there is no `reversal` of loading of these modules and so these won't interfere with DynaLoader mechanism.