softwarecollections
April 2013
softwarecollections@lists.fedorahosted.org
- 3 participants
- 2 discussions
Hash-bang line for scripts using a software collection
by Andrew Ford
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
11 years
- 2
- 1
Help diagnosing problems with scl build
by Doran L. Barton
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
11 years
- 2
- 1
- ← Newer
- 1
- Older →