softwarecollections April 2013

softwarecollections@lists.fedorahosted.org

3 participants
2 discussions

Hash-bang line for scripts using a software collection
by Andrew Ford 25 Apr '13

25 Apr '13

Is there an easy way to set up a script to invoke a software collection interpreter? I had thought of something like: #!/usr/bin/scl enable myperl5xx perl but that just displays the scl error/usage page. I know that I could use #!/opt/myprovider/myperl5xx/root/usr/bin/perl but that doesn't adjust $ENV{PATH}, $ENV{MANPATH}, etc as it doesn't execute the collection's enable script. Andrew

2 1

Help diagnosing problems with scl build
by Doran L. Barton 23 Apr '13

23 Apr '13

I've run into some odd problems building a "scl-ified" package and I'm hoping other list subscribers who are smarter and/or more experienced with package builds than me can shed some insight on what's going on here. I'm building a software package called Freeside, which is a billing system written primarily in Perl. The package website is <http://www.freeside.biz/> and I'm building their 3.0 version. To do this, I used the freeside.spec file they include in their tarball. It hadn't been updated since version 2.1, so I updated it and made some changes to it to get it to build. Once I got a successful build, I ran spec2scl on the modified spec file. This created some interesting issues. Most notably, there were some lines in the spec file which invoked Perl to make some inline changes to makefiles. Stuff like this: perl -pi -e 's|/usr/local/bin|%{_bindir}|g' fs_selfservice/FS- SelfService/Makefile.PL spec2scl modified lines like this with: %{?scl:scl enable %{scl} "} perl -pi -e 's|/usr/local/bin|%{_bindir}|g' fs_selfservice/FS- SelfService/Makefile.PL %{?scl:"} This doesn't work. As I thought about it, I came to the conclusion I didn't really need these simple text file manipulations to be done by the Perl interpretter provided by the perl514 collection. It would be just fine if these commands were done by the system Perl interpretter (5.8 or 5.10). So, I stripped all these commands out of the 'scl enable' wrappers in the scl-ified spec file. I'm building this package with mock and the mock build of the scl-modified spec file seems to go fine until the %install phase. The spec file has a %makeinstall macro and that issues a long 'make install' line using the root Makefile for the Freeside package. The Makefile has a target called install-perl-modules that looks like this: install-perl-modules: perl-modules install-rt-initialdata [ -L ${PERL_INC_DEV_KLUDGE}/FS ] \ && rm ${PERL_INC_DEV_KLUDGE}/FS \ && mv ${PERL_INC_DEV_KLUDGE}/FS.old ${PERL_INC_DEV_KLUDGE}/FS \ || true cd FS; \ make install UNINST=1 #install this for freeside-setup install -d $(DIST_CONF) #install conf/[a-z]* $(DEFAULT_CONF) #CVS is not [a-z] install `ls -d conf/[a-z]* | grep -v CVS | grep -v '^conf/registries'` $(DIST_CONF) When it reaches the 'install -d $(DIST_CONF)' line, it doesn't prepend any DESTDIR or PREFIX and ends up trying to create the directory /usr/local/etc/freeside, which as a non-privileged user, it can not. I've attached the spec files (before and after the spec2scl) if anyone wants to inspect them to see if there's anything obvious I've done to mess things up. Otherwise, I'm wondering if I've tripped over some weird makefile bug. -- Doran L. Barton <doran(a)bluehost.com> - Senior Developer, Bluehost, RHCE "Let's enjoy your life. Sometimes you can do it only with lovely color." -- Japanese stationary packaging

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

softwarecollections April 2013