💾 Archived View for thrig.me › tech › somedirectory.txt captured on 2023-01-29 at 03:16:33.
-=-=-=-=-=-=-
# somedirectory.spec - a method for having a single directory with many
# CPAN modules on RedHat systems, to avoid wasting time trying to build
# individual CPAN modules into individual RPMs
#
# you'll probably want a different directory name and different package
# name. the gist is to 1) setup cpanm and local::lib to install perl
# modules to somedirectory 2) maintain a cpanfile of modules for cpanm
# to install 3) install those modules to somedirectory 4) build
# somedirectory into a tarball 5) build the tarball into an RPM 6)
# install the RPM on target systems 7) setup the environment on the
# target systems to list somedirectory in PERL5LIB
#
# for the initial setup, read the cpanm and notably the local::lib docs
# on how to make installs go to /usr/local/somedirectory or whatever.
# this path should be outside of those maintained by the vendor
#
# adding a new module looks something like
#
# echo New::Module >> cpanfile
# cpanm --installdeps .
# ... increment the release number in this file ...
# cd /usr/local && tar czpf ~/rpmbuild/SOURCES/somedirectory.tar.gz somedirectory
# rpmbuild -ba somedirectory.spec
#
# then signing the RPM, committing cpanfile to git or whatever, etc.
# this should be fairly trivial to automate more. use `cpan-outdated`
# with somedirectory in PERL5LIB to see what updates are available on
# CPAN (which you would also need to do for modules installed as
# individual RPMs...)
#
# on the end systems, there are various ways to set PERL5LIB, e.g. for
# systemd services one can
#
# Environment=PERL5LIB=/usr/local/somedirectory/lib/perl5
#
# or you can 'use lib ...' in individual scripts, among other methods.
# the vendor stuff should be unaffected, unless your PERL5LIB
# environment changes get picked up by a vendor script, and that vendor
# script has a problem with an updated module under somedirectory, in
# which case don't let the vendor script see the modified PERL5LIB, or
# use some other method, such as installing a totally new perl elsewhere
#
# I moved to this method in late Centos 7 and early Centos 8 due to too
# much time being spent trying to install CPAN modules for use with the
# RedHat perl with a 1:1 mapping between too many CPAN distributions and
# the resulting RPMs. this did not scale to a single sysadmin with
# limited time on their hands. other methods would be to 1) dedicate the
# manhours necessary to make round CPAN modules always fit into square
# RPM holes while somehow not running into version conflicts between the
# modules necessary from CPAN versus what the vendor provides in base
# (maybe you can make that work for you?) 2) install a totally different
# Perl and the necessary modules somewhere else. there are lots of ways
# to do this, and it avoids the need to set PERL5LIB...possibly via a
# giant directory tree installed by RPM, as shown by this file 3) other
Name: somedirectory
# NOTE version is tied to major Centos release, instead increment the
# release when there are updates or new modules
Version: 8.0
Release: 1%{?dist}
Summary: All the perl modules
Group: Development/Tools
License: It's complicated
Source0: %{name}.tar.gz
# TODO how also say "but not the next higher major version"? in the
# meantime, don't copy the Centos 8 RPM into the Centos 7 tree
Requires: redhat-release >= %{version}
BuildRequires: rsync
# we install to a non-vendor directory; do not spam the requirements
# database with our perl modules that will then conflict with the vendor
#Autoreq: 0
Autoreqprov: 0
Autoprov: 0
%description
The /usr/local/somedirectory directory that contains various Perl modules.
%prep
%setup -q -n %{name}
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/somedirectory
rsync -a . $RPM_BUILD_ROOT/usr/local/somedirectory
%files
/usr/local/somedirectory/*
%changelog
TODO