sodface wrote: > I was going that direction, building slimserver-vendor modules against > the current Alpine Perl version and then combining with the unix-noCPAN > tar file to get a working installation. >
There likely isn't an elegant solution to the dependency issues without including a specific version of perl in your package. You can either supply binary modules for multiple perl versions (which is what the LMS deb packages do), but you won't be able to create these with a APKBUILD. Or you can provide the binary modules for only one perl version (i.e. the one on the machine where the APKBUILD is done), which means it will not work on different Alpine versions (or even the same Alpine version if perl gets upgraded - not sure if this happens). I don't know if your package can depend on a specific perl version, but even if, it's won't really help, as Alpine seems to remove old packages from the repo, so users couldn't install them anyway. Since I'm not familiar with Alpine, I don't know if including perl in your package is acceptable (on the distros I know, it wouldn't be). If it isn't, and Alpine doesn't upgrade perl major versions within a Alpine version, you'd have to provide a different LMS package for each Alpine version. If it does, you're out of luck. > > The old module sources sort of bothered me and then I read this post by > you: > https://forums.slimdevices.com/showthread.php?107040-Howto-update-perl-modules-bundled-with-LMS > First, note that there are non-binary modules in lms/CPAN as well (e.g. Algorithm::C3), which are included in the non-CPAN tarballs. I've never bothered to update those. fwiw, the last build I did uses the following versions and has run without any obvious issues for ~3 months: Code: -------------------- Audio-Cuefile-Parser-0.02.tar.gz Module-Build-0.4224.tar.gz Audio-Scan-1.01.tar.gz Mozilla-CA-20180117.tar.gz Canary-Stability-2012.tar.gz Net-SSLeay-1.85.tar.gz Class-C3-XS-0.14.tar.gz Sub-Name-0.21.tar.gz Class-XSAccessor-1.19.tar.gz Sub-Uplevel-0.2600.tar.gz DBD-SQLite-1.64.tar.gz Template-Toolkit-2.26.tar.gz DBI-1.641.tar.gz Test-NoWarnings-1.04.tar.gz Data-Dump-1.23.tar.gz Test-Warn-0.32.tar.gz Digest-SHA1-2.13.tar.gz Tree-DAG_Node-1.29.tar.gz EV-4.22.tar.gz Types-Serialiser-1.0.tar.gz Encode-Detect-1.01.tar.gz XML-Parser-2.44.tar.gz ExtUtils-CBuilder-0.280224.tar.gz YAML-LibYAML-0.63.tar.gz HTML-Parser-3.72.tar.gz common-sense-3.74.tar.gz HTML-Tagset-3.20.tar.gz db-5.3.28.tar.xz IO-AIO-4.34.tar.gz expat-2.2.6.tar.bz2 IO-Interface-1.09.tar.gz ffmpeg-0.8.4.tar.bz2 IO-Socket-SSL-2.059.tar.gz giflib-4.2.3.tar.gz Image-Scale-0.14.tar.gz libexif-0.6.21.tar.bz2 JSON-XS-3.03.tar.gz libjpeg-turbo-1.5.3.tar.gz Linux-Inotify2-1.22.tar.gz libmediascan-0.1.tar.gz MP3-Cut-Gapless-0.03.tar.gz libpng-1.6.37.tar.xz -------------------- > > Which got me second guessing the approach I was taking. I'm thinking > about taking a mixed approach and taking the current Alpine Perl > packages (many of the modules are in the repos too) building anything > that's missing and then bundling everything together as a separate > package with the Perl stuff self contained with LMS. > I don't see any point in this approach - you will need to build the binary modules specifically for LMS anyway and cannot re-use the ones installed. The only advantage is that you could re-use the already downloaded sources in the local cache (provided you have run the official APKBUILDs and do not just use the binary package), but then you would build the modules twice without needing to (and have them installed twice as well). Much easier to list the module sources in the sources for the APKBUILD, then the akp tool will download them for you and you can use the version from the local cache in your build script (I guess - at least, with gentoo's portage, that would work) > > That way the Perl and modules match the Alpine versions as of today but > they are self contained and would remain static as Alpine does updates. > I could then update the package at a later date if I felt the need. > There really is no advantage in the LMS CPAN modules matching the Alpine versions unless you plan to actually use the Alpine versions for LMS (which I really do not recommend - the Gentoo ebuild tried that, and it was a disaster -there's a reason it's now a binary package with it's own modules) > > I've looked at some of Gentoo's ebuild files for LMS and they are a > little scary (to me). > The Gentoo ebuilds I'm aware of are either 'ancient and broken' (http://gpo.zugaina.org/AJAX/Ebuild/38526667/View) or ' binary packages' (https://github.com/hickinbottoms/logitechmediaserver-bin-ebuild-for-gentoo/blob/master/logitechmediaserver-bin-7.9.2_pre20190615.ebuild.in), which means the ebuild does not include actually building it. Some random thoughts: Make sure your versions of faad, sox etc. don't conflict with the ones provided by Alpine Include your own Slim/Utils/OS/Custom.pm ('example' (https://github.com/hickinbottoms/logitechmediaserver-bin-ebuild-for-gentoo/blob/master/files/gentoo-filepaths.pm)) to set pathnames. If you need OpenRC scripts, 'this one' (https://github.com/hickinbottoms/logitechmediaserver-bin-ebuild-for-gentoo/blob/master/files/logitechmediaserver.init.d) for Gentoo should get you started. 'Various SW' (https://www.nexus0.net/pub/sw/): Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ... 'Various HowTos' (https://www.nexus0.net/pub/documents/LMS/): build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ... ------------------------------------------------------------------------ Roland0's Profile: http://forums.slimdevices.com/member.php?userid=56808 View this thread: http://forums.slimdevices.com/showthread.php?t=111401 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
