Gnashley, I often do post install tasks such as copying config files to certain locations and adding content to existing config files. An example:

echo "Make cache dir"
mkdir /opt/squid/var/cache
echo "Set perms on cache logs directories"
chown -R nobody.nogroup /opt/squid/var/cache
chown -R nobody.nogroup /opt/squid/var/logs
echo "Edit squid.conf"
joe /opt/squid/etc/squid.conf
echo "Create squidpwd and add user"
htpasswd -c /opt/squid/etc/squidpwd rpedrica
echo "Add startup info to rc"
echo "rm /opt/squid/var/logs/*.pid" >> /etc/rc.d/rc.local
echo "/opt/squid/sbin/squid" >> /etc/rc.d/rc.local

Can I simply add these between 'make_doinst' and 'make_package' and will they be parsed correctly? I'm specifically interested in file copies and the echo'ing of content to another file. Presumably, an interactive item such editing a file will not work correctly ....

Last question: Where I normally use 'make opt1 && opt2' from the command line, I think I've worked out that I should use 'make opt1 opt2' for -i - is this correct?

Regards, Robby

You can add commands between any of the normal instructions. Usually, it's handy to put them just after fake_install -unless the commands are meant to undo something that is done automatically. The routines after fake_install do a lot of perms checking which may be beneficial, but if you are making 'unusual' directories it won't catch them. You sometimes need or want to clean up or add to what is done with the man-pages and docs. Very commonly, you'll want to add some arbitrary docs to the package.
src2pkg provides convenient 'shortcut' variables for the most commonly used locations: $CWD is the loaction where src2pkg is run from, $SRC_DIR is the location of the unpacked sources. $PKG_DIR is the toplevel of the package tree where everything gets assembled before compressing the final package. You can also use $DOC_DIR -this is the full path to the docs, normally: $PKG_DIR/usr/doc/$NAME-$VERSION

So, say you want to copy some html files from the working dir into the docs:
cp $CWD/*.html $DOC_DIR
will do the trick if you put it after the normal docs are done. If you do it before, be sure to create the directory first:
mkdir -p $DOC_DIR
cp $CWD/*.html $DOC_DIR

If you need to copy stuff from the sources into the package:

mkdir -p $PKG_DIR/opt/squid/stuff
cp $SRC_DIR/somedir/oddfile $PKG_DIR/opt/squid/stuff

Mostly, stuff like this:
chown -R nobody.nogroup /opt/squid/var/cache
chown -R nobody.nogroup /opt/squid/var/logs

should go in your doinst.sh script.
And it should be very 'safe' and correct by using grep to make sure that it is necessary:
That's just a quick example which is not completely correct. But it gives you the idea. Study some of the doinst.sh scripts from Alien Bob Robby Workman or Pat Volkerding for more sane examples.

Actually, I have a build of squid which may help you out -it has not been tested, but some of the ideas or code came from someone who was actually using the program. Anyway, the build shows a fairly complete example of how to do a complex setup using src2pkg. See here:
http://distro.ibiblio.org/pub/linux/...-2.6.stable17/

The still-unreleased development version of src2pkg does even more for you seamlessly. But what you are using can automatically handle rc.d files for you. In other words, if you write a good rc.d/rc.$NAME file, all you have to do is place it in the $CWD and it will automatically be added to the package, plus src2pkg will add lines to the doinst.sh which take care of writing the entry in rc.local when the package is installed.

FWIW, src2pkg also does the same thing wiith png or xpm icons, desktop files and others -just placing them in CWD causes them to be placed in the package. the new version does lots more of this and better -I promise I'm gonna release pretty soon as it has been a long time...

Oh, and yes, if you need to use multiple 'rules' with make just add them with:
-m='make deps all'
or
-i='make install install_data'

You might want to look at the SlackBuild script for squid. It packages everything up sanely and avoids using things like /opt or dropping everything into /var/lib/squid. Just a suggestion.

This is generally bad form. The thing that really screams at me is the use of htpasswd in the doinst.sh script. You can do this, and it will behave as you expect, but generally speaking you want to avoid anything that requires user intervention during package installation/upgrade. Imagine your surprise when you run an upgradepkg *.tgz in a screen session then return to the box months later to discover that your upgrades never completed because no one was present to enter the password. Also, "$grep" will execute the value of the "grep" environment variable, which isn't set, so the above if statements will always be false as bash will try to execute /opt/squid/var/logs instead. Generally speaking, avoid the use of variables in the doinst.sh script unless you specifically set them there. I'm unsure if pkgtools will read the user's full environment, but if so, that could lead to unexpected results and seriously broken systems.

Also, slackbuilds.org's build script includes an rc script for squid which would make starting and stopping more sane.

Thanks Gilbert - that's very comprehensive. I have a newer post as well and you may have answered one or 2 questions on that. I've had a look at your squid config and learnt a few things for instance using EXTRA_SOURCES to list files you'll work with during that session. I'm just wondering what is the difference between doing something in doinst.sh and doing it in the src2pkg script itself?

'FWIW, src2pkg also does the same thing with png or xpm icons, desktop files and others -just placing them in CWD causes them to be placed in the package' - I assume you would have to include them with EXTRA_SOURCES as above or not?

Regards, Robby

Doinst.sh - I just realised what this might be: if you are not using src2pkg to build the package but are using the built package to install ( ala installpkg <pkg> ) you would still need some mechanism to move/control files that are outside of the install location directory - src2pkg wouldn't be there to execute these ...?

Regards, Robby

Of course, doinst.sh files are part of many packages, but are not always required. They get run *after* the package is untarred in /.

+Alan Hicks+, I just meant to give a crude example. Obviouls one wouldn'Ät want to put user specific (and usually not interactive) stuff in a doinst.sh script. That was reall sloppy and I've edited the original post a little. (If it still is not perfect, bear this in mind: I got up very early this morning to drive my fasting son to the doctor for a blood test -he was screaming for an hour because Mommy told him it would hurt a little). Anyway, I didn't expect that rpedica would use that code directly -hope he studies lots of doinst.sh scripts to see what is needed for a 'perfect' package when installing daemon-like progs...

rpedica, SOURCE_URL (or BASE_URL and SOURCE_NAME) and EXTRA_SOURCES only relate to files which will be downloaded by src2pkg for the build. i had forgotten that the squid build was a comprehensive example of some advanced features of src2pkg.

Just as an example, do this:
Login as root and create a new empty directory. Make sure your internet connection
is up, then cd into the new dir and run:
src2pkg http://distro.ibiblio.org/pub/linux/.../squid.src2pkg

This will first download the src2pkg script, which then will download the sources and the doinst.sh script and do the build. If it were some other package, you could usually do this as a normal user, but since the squid build calls chown you have to be root to do a proper build.

Here's a safer example, as you can do it as a normal user:
src2pkg http://distro.ibiblio.org/pub/linux/...i.src2pkg.auto
That builds a small disk info utility.
The SOURCE_URL and EXTRA_SOURCES are part of src2pkg's ability to act as a source repo frontend. In fact, for the seconf example, add the '-I' option and you will see that the package gets installed also. Not quite as comprehensive as 'emerge', but you get the idea.
BTW, do look at Alien's SlackBuild for squid. It is always a good idea to have a look around at other's work -even if you 'translate' it into a src2pkg script.

Thanks Alan for the comments. I've used slackBuilds on occasion but generally have a set of scripts I've written myself to compile from source, a set of apps that I use often - they're of course very simple/raw. These are mainly for servers so once done, it's easy to do again. You'll probably grate your teeth on this but I've no qualms about installing straight over an existing package install ( I know when to keep copies of config files by now ... )

So these package build systems are fairly new to me but I thought I'd give them a go in any case. While this thread is not a comparison of the various systems, I do find the slackBuild scripts more complex than src2pkg although if there is a slackBuild script available, you have to do little more than run it.

I have to say though that when it comes to compiling dependencies and packages for av stuff like dvdrip, vlc, ffmped and transcode, I always have a bit of fun. So I'm seeing if these can ease my life a bit - not that I do the above packages often : (

Anyway, I like both options above and am taking some time out to learn them ... wrt /opt, there are a few apps I just prefer there. If you ask me why, I'd just say it feels right ; ) Strange though that working on Slack for the last 12 years or so, I've gotten so used doing things 'by hand' that these completely past me by until I sat down and thought about it.

Regards, Robby