SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
You can change INSTALL_LINE to do what you want. Although, why do you want to? Current slackware packages are already provided, and IIRC the lilypond docs say that almost all normal users shouldn't even try building it.
I tried using the -i switch to set the install command (I assume that's the same as INSTALL_LINE?), but the problem was that src2pkg wouldn't accept a filename ending in .sh (I assume it's looking for an archive to unpack).
There is a Slack package available on the download site, but it's for Slack 11.0. I'm running 12.0, which I believe has some significant differences in terms of libraries and such. I'm not trying to compile it from source (already saw the warning on the site about it), but rather use the provided shell script installer to install the x86 binaries. It sounds like the installer might provide a way to uninstall as well, but I'd rather monitor the installation and have it tracked as a slackpkg instead.
Sorry for not clarifying enough. The .sh file is the installer/archive, it's not a script within an unpacked directory. It looks like it's a shell script with a binary .tar.bz2 stuck on the end (not sure how they did that). You run the script and it unpacks and installs itself. If I run it in order to unpack it, it will get installed as well. If I try to use src2pkg to unpack and install it (with, say, "src2pkg -S -i='sh lilypond-xxx.sh' lilypond-xxx.sh"), I get "Unrecognized option" since it's not a valid .tar.gz file.
I'm not one to leave my users in a lurch, so here is a src2pkg script for lilypond. I couldn't get it to work using the -S and -i options(they do work for some interactive scripts). But I tore the guts out of the installer script for creating the wrappers and links. You should be able to use this with other versions or prefixes without any trouble. src2pkg will produce the slack-desc and doinst.sh for you, but you may wish to edit the slack-desc and rebuild to include the changes.
## src2pkg script for: lilypond
## src2pkg Copyright 2005-2007 Gilbert Ashley <email@example.com>
# to use with a different version of lily pond,
# just edit the following line, the SOURCE_NAME and the ALT_VERSION
sh lilypond-2.11.36-1.linux-x86.sh --tarball &> /dev/null
# To install to a differerent prefix, just edit the PRE_FIX line
# Get the functions and configs
. /usr/libexec/src2pkg/FUNCTIONS ;
# do_all_processes can substitute these 16 steps:
mkdir -p $PKG_DIR/$PRE_FIX/bin
cat<<EOF > "$PKG_DIR/$PRE_FIX/bin/lilypond"
exec "/usr/lilypond/usr/bin/lilypond" "\$@"
mkdir -p $PKG_DIR/usr/doc/$NAME-$VERSION
cp -a $SRC_DIR/license/* $PKG_DIR/usr/doc/$NAME-$VERSION/
rm -rf $SRC_DIR/license
mkdir -p $PKG_DIR/$PRE_FIX/lilypond
cp -a $SRC_DIR/usr $PKG_DIR/$PRE_FIX/lilypond/
cat<<EOF > "$PKG_DIR/$PRE_FIX/bin/lilypond-wrapper.guile"
exec "/$PRE_FIX/lilypond/usr/bin/guile" -e main "/$PRE_FIX/lilypond/usr/bin/lilypond" "\$@"
cat<<EOF > "$PKG_DIR/$PRE_FIX/bin/lilypond-wrapper.python"
exec "/$PRE_FIX/lilypond/usr/bin/python" "/$PRE_FIX/lilypond/usr/bin/lilypond" "\$@"
chown root:root $PKG_DIR/$PRE_FIX/bin/*
chmod 755 $PKG_DIR/$PRE_FIX/bin/*
( cd $PKG_DIR/$PRE_FIX/bin
for a in abc2ly musicxml2ly convert-ly midi2ly etf2ly lilypond-book mup2ly ; do
rm -f $a;
ln -s lilypond-wrapper.python $a;
for a in lilypond-invoke-editor ; do
rm -f $a;
ln -s lilypond-wrapper.guile $a;
# src2pkg - Copyright 2005-2007 Gilbert Ashley <firstname.lastname@example.org>
Thanks for the script. I have a few more questions/comments.
1. I used the script to build the package, and went to check the doinst.sh that was created. It has a lot of lines like:
( cd usr/local/lilypond/usr/lib ; rm -rf libjpeg.so.62 )
( cd usr/local/lilypond/usr/lib ; ln -sf libjpeg.so.62.0.0 libjpeg.so.62 )
Is something weird going on with prefixes here?
2. Still trying to figure out the details of src2pkg... Am I right that making any changes to the default doinst.sh or slack-desc files requires rebuilding the entire package? This is no problem here, but I can imagine that being annoying for a package that takes 10-15 minutes to compile needing to be built twice.
3. I was confused for a while trying to run that script until I realized what was wrong. When a file is edited with vim and saved (say foo.src2pkg.auto), a backup file is created (foo.src2pkg.auto~). When "src2pkg -X" is run, it will find that backup file instead of the original one, and say "No src2pkg script found." Something is wrong around line 378 of src2pkg.
Glad thyt worked for you:
1. Those prefixes are, indeed, correct. You can check any official doinst.sh to see that this is the way they should look (withotu the leading /). This is because when you run installpkg from the installer or using the ROOT= variable, th epath should start from the current working directory. For instance ROOT=/tmp/mnt installpkg something.tgz cd's into /tmp/mnt and installs the package there. If the doinst.sh had absolute paths, the package would be installed to the real root '/' instead of the /tmp/mnt/somepath
2.Yes, you must rebuild to inclde any changes that you make to the default doins.sh or slack-desc files that are created. Note that the files that src2pkg puts in the current directory are copies of the files which are placed in the package tree. In most cases, the copies in the current directory have a 'new.' prefix on the name. In order to use these files in the package you must change the name to remove the prefix, otherwise they can be overwrtten by the next build. For instance, if you use the -N or -A options repeatedly the files get generated again -until you change the name. This is done because the files are essential to the package. But, changing the name to the real one signals srcpkg that you want it to use the files you provide. The same is true of *.src2pkg.auto scripts which are gernerated. If you run with -N or -A option repeatedly the get created again. Once you change the name to simply *.sr2pkg then the file gets used as is.
10-15 is not too long to wait for a good package. src2pkg probably saves you several minutes of time over doing it manually. It's best to rid yourself of the idea that you'll get a perfect package on the first build. Nearly any package that has any complexity to it, like ones that need init files, or that are hard to setup, will take more than one build to get right. Many times it will take a dozen or more builds to get a package just right. You could cheat and alter the file, replace them in the package tree and then run makepkg in there -if no recompiling is needed. Just because srcpkg can create 'a' package the first time doesn't mean that the package will be perfect. Form a habit of always checking the content -there are some things that just can't be checked programatically. The real work and 'art' of making packages is in getting these small details correct so that if you were to share the package with someone else it would 'just work'. (Imagine how much time and work it takes to debug build scripts for KDE or mozilla which take many hours to compile and do all sorts of weird things when they install! Should make you more grateful for the SlackBuilds and pre-made packages you use)
3. Yeah, there's a pretty weak bit of code there that looks for scripts to run in the current directory. It's easily confused by multiple files being present. Another user just e-mailed about the same problem yesterday. I'll work on improving that for the next release which is coming out in a few days.
Thanks for posting back -I had been wondering what the outcome was. Still think you oughta use /usr instead of /usr/local, but you can do whatever you want.