src2pkg-1.7 released

tuxdev · 12-21-2007, 12:07 AM

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.

jrdioko · 12-21-2007, 12:16 AM

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.

gnashley · 12-21-2007, 01:55 AM

If you have already unpacked the archive, cd into the open directory and use:
"trackinstall -S -i='sh lilypond-xxx.sh'".

If youwant to try it with src2pkg, let it do the unpacking also:
"src2pkg -S -i='sh lilypond-xxx.sh'" lilypond-xxx.tar.gz
Of course sunstitue the correct verison and archive suffix...

src2pkg is not for use with already unpacked archives. Sue trackinstall when you want to work that way.

jrdioko · 12-21-2007, 02:17 AM

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.

titopoquito · 12-21-2007, 04:33 AM

You can of course extract the tarball from it yourself and then run src2pkg on it. Look at lines 67-71 in the lilypond...sh how they do it.

/bin/bash · 12-21-2007, 06:07 AM

Always one of my favorite utilities!

gnashley · 12-21-2007, 08:24 AM

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.

Code:

#!/bin/bash
## src2pkg script for: 	lilypond
## src2pkg Copyright 2005-2007 Gilbert Ashley <amigo@ibilio.org>

# 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

SOURCE_NAME='lilypond-2.11.36-1.linux-x86.tar.bz2'
ALT_NAME='lilypond'
ALT_VERSION='2.11.36'
ARCH='i486'
BUILD='1'
PRE_FIX='usr'

# Get the functions and configs
. /usr/libexec/src2pkg/FUNCTIONS ;

# do_all_processes can substitute these 16 steps:

pre_process
find_source
make_dirs
unpack_source
fix_source_perms

# configure_source
# compile_source
# fake_install

mkdir -p $PKG_DIR/$PRE_FIX/bin
 cat<<EOF > "$PKG_DIR/$PRE_FIX/bin/lilypond"
#!/bin/sh
export LD_LIBRARY_PATH='/usr/lilypond/usr/lib/'
exec "/usr/lilypond/usr/bin/lilypond" "\$@"
EOF

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"
#!/bin/sh
export PYTHONPATH="/$PRE_FIX/lilypond/usr/lib/lilypond/current/python/:/usr/lilypond/usr/share/lilypond/current/python/:\$PYTHONPATH"
export GUILE_LOAD_PATH="/$PRE_FIX/lilypond/usr/share/lilypond/current/"
export LD_LIBRARY_PATH="/$PRE_FIX/lilypond/usr/lib/:\$LD_LIBRARY_PATH"
exec "/$PRE_FIX/lilypond/usr/bin/guile" -e main "/$PRE_FIX/lilypond/usr/bin/lilypond" "\$@"
EOF

 cat<<EOF > "$PKG_DIR/$PRE_FIX/bin/lilypond-wrapper.python"
#!/bin/sh
export PYTHONPATH="/$PRE_FIX/lilypond/usr/lib/lilypond/current/python/:/usr/lilypond/usr/share/lilypond/current/python/:\$PYTHONPATH"
export GUILE_LOAD_PATH="/$PRE_FIX/lilypond/usr/share/lilypond/current/"
export LD_LIBRARY_PATH="/$PRE_FIX/lilypond/usr/lib/:\$LD_LIBRARY_PATH"
exec "/$PRE_FIX/lilypond/usr/bin/python" "/$PRE_FIX/lilypond/usr/bin/lilypond" "\$@"
EOF

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;
 done
 for a in lilypond-invoke-editor ; do
   rm -f $a;
   ln -s lilypond-wrapper.guile $a;
 done
)

fix_pkg_perms
strip_bins
create_docs
compress_man_pages
make_description
make_doinst
make_package
post_process

# src2pkg - Copyright 2005-2007  Gilbert Ashley <amigo@ibiblio.org>

jrdioko · 12-24-2007, 04:24 PM

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:

Code:

( 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.

gnashley · 12-25-2007, 02:26 AM

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.