Recently I wanted to run LMS on our brand new FreeNAS FreeBSD 12 server. I discovered multiple ports and HOW-TOs for that platform. We grabbed the logitechmediaserver plug-in that installed with just few clicks on our default setup. It turned out that, although it was easy to install, that particular port had two issues: not using the LMS-fork of faad, breaking ALAC files, and not using the LMS-fork of the CPAN libraries.
The latter means that if I update Perl in my LMS Jail, LMS will break. Indeed that happened to me a couple year ago, and I posted a forum article on how to recover from it.
I now know about, (and showed the guy who did the port I'm running) the slimserver-vendor tree that contains a very complete set of CPAN libraries (and other stuff) that locks in all the nitty-gritty bits to keep LMS working.
There's another competing FreeBSD port that includes a different fork of the CPAN libraries. Although I know that other fork has fewer modules, I don't know what the rationale was for picking them.
Recognizing some guiding high-level principles:
1. Minimize the ongoing maintenance load both for individuals and the LMS community as a whole.
2. Maintain, as much as possible support for viable legacy platforms.
3. Make it as easy as possible for new people to adopt best practices.
4. Make it as easy as possible to do new stuff.
5. Minimize the additional effort required to avoid breaking old stuff.
I would like to open a discussion about the current state of https://github.com/Logitech/slimserver-vendor/CPAN/
In https://github.com/Logitech/slimserver-vendor/pull/83, contributor simonef proposed a much shorter list of CPAN modules to lock in.
It seems to me that the more we can get LMS to adopt "current upstream" tool chain and support utilities, the less work for the LMS community to keep the LMS fork maintained.
However, there may be modules that simonef left out that have a material impact on legacy platforms and therefore should be retained in the fork.
As a starting point, how about we amend the README in the CPAN directory to state which versions of LMS that tree supports? simonef seems to have drawn a line recently at 8.0 for his fork.
As a next step, I'd like to understand why simonef removed the modules he removed, in his fork at: https://github.com/simonefil/slimserver-vendor
I've started reading the history, and it looks like simonef has done a lot of work that might be beneficial to the canonical version at https://github.com/Logitech/slimserver-vendor/CPAN/, but also understanding all the work he has done does indeed seem like a non-trivial task.
The latter means that if I update Perl in my LMS Jail, LMS will break. Indeed that happened to me a couple year ago, and I posted a forum article on how to recover from it.
I now know about, (and showed the guy who did the port I'm running) the slimserver-vendor tree that contains a very complete set of CPAN libraries (and other stuff) that locks in all the nitty-gritty bits to keep LMS working.
There's another competing FreeBSD port that includes a different fork of the CPAN libraries. Although I know that other fork has fewer modules, I don't know what the rationale was for picking them.
Recognizing some guiding high-level principles:
1. Minimize the ongoing maintenance load both for individuals and the LMS community as a whole.
2. Maintain, as much as possible support for viable legacy platforms.
3. Make it as easy as possible for new people to adopt best practices.
4. Make it as easy as possible to do new stuff.
5. Minimize the additional effort required to avoid breaking old stuff.
I would like to open a discussion about the current state of https://github.com/Logitech/slimserver-vendor/CPAN/
In https://github.com/Logitech/slimserver-vendor/pull/83, contributor simonef proposed a much shorter list of CPAN modules to lock in.
It seems to me that the more we can get LMS to adopt "current upstream" tool chain and support utilities, the less work for the LMS community to keep the LMS fork maintained.
However, there may be modules that simonef left out that have a material impact on legacy platforms and therefore should be retained in the fork.
As a starting point, how about we amend the README in the CPAN directory to state which versions of LMS that tree supports? simonef seems to have drawn a line recently at 8.0 for his fork.
As a next step, I'd like to understand why simonef removed the modules he removed, in his fork at: https://github.com/simonefil/slimserver-vendor
I've started reading the history, and it looks like simonef has done a lot of work that might be beneficial to the canonical version at https://github.com/Logitech/slimserver-vendor/CPAN/, but also understanding all the work he has done does indeed seem like a non-trivial task.