Date: Fri, 20 Jun 2025 11:08:50 +0200 From: Trenton Schulz <trenton@norwegianrockcat.com> To: FreeBSD Ports ML <Freebsd-ports@freebsd.org> Subject: Seeking assistance (or advice) on bug 283493 (audio/lyrionmusicserver) Message-ID: <874iwaye0y.fsf@norwegianrockcat.com>
next in thread | raw e-mail | index | archive | help
TL;DR: Could someone take a look and commit bug 283493, please? I also wonder about how best to deal with "vendor" versions of Perl modules in the future. Longer version: Hello, I'm the maintainer of audio/logitechmediaserver port and late last year the project changed to Lyrion Music Server and I created a new port for that (bug 283493). It basically is the same port with a new name, all the updates of the latest released version, the "encumbered" files removed so that it is only a GPL program (and thus built as a package), and changes made so that it complies for arm64. I have run it locally since December and it has worked well. With the perl update, the audio/logitechmediaserver port fails. I started looking at this, but found that the new port works fine with Perl 5.40, so I just updated the patch to remove the logitechmediaserver port in place of the new port. I hope this doesn't make the patch too complex (although one does need to use git apply to create and remove the files). Would someone be willing to take a look and commit it to the tree? Now asking for advice: There is a long-standing "issue" with audio/logitechmediaserver, which audio/lyrionmusicserver also has. Both build and install some Perl modules for itself from a vendor branch during build. It's an issue only that some of the modules are available as ports (albeit at different version numbers). I understand that these other modules are not a problem as the server sets its own module path, but it is some duplication and might not be as pure as desired. I have always run this in a jail, so my understanding may be wrong. I tried taking a look at fixing this for lyrionmusicserver but quickly arrived in dependency problems that weren't easily fixable at first glance. This seemed to make the update even messier. I would rather have a working port that is installable by people (I keep getting emails asking about this), and work slowly on resolving the dependency issues (if possible) than wait for a port that is "perfect". If there is some documentation or suggestions on how to trace Perl module issues, I would be happy to look at them. Best regards, -- Trenton
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?874iwaye0y.fsf>