I've released a new version of PkgBuild which now includes support for the Jam build system and a new utility called 'tracklist' which simply tracks a command and produces a FILELIST of files and directories created by the command -useful if you just want to know what a command is doing- for instance tracking the files installed when you run the install.sh script included with many binary-only programs like opera, etc. tracklist does not interfere with what happens -it just lists files and dirs.

You can download the latest version(0.9.9) here:
http://distro.ibiblio.org/pub/linux/...migo-PkgBuild/

Users of past versions of src2pkg and trackinstall will want to take note of the new command-line syntax which is now unified between the two programs so common options are the same under both programs.

Error handling has been improved in the PkgBuild functions and a function added for giving the package a name other than that used in the tarball -for instance renaming a package to all lowercase letters when the tarball includes capital letters.

If you're not much of a script writer, don't despair. Just type 'src2pkg -n tarballname.tar.xx' to generate a PkgBuild script and slack-desc file for the tarball.

I am sorry for the stupid question, but where can we download the new version from?

Cool. I suggest a -s option for packages with install.sh or similar. It's equavalent to "-i='install.sh' -r=''"

Great stuff, Thank you!

Excellent idea tuxdev. I was able to hack that to work pretty quickly, but it pushed me into cleaning up and moving lots of code whixh has taken awhile. But now you can run
'trackinstall -S' to run a shell installer and make a package from using the command:
'sh install.sh'. This works even if it's an interactive installer. I've tested with opera and several flash-player installers. You can change the commands by using the -i and -r options.
trackinstall will also now write a TrackBuild script for you which you can use to add or alter the content of the package.
I've also included a switch (trackinstall -P) for turning off correction of permissions in the sources. This may be helpful for packaging CVS or SVN sources, or sources you have compiled as a normal user.
trackinstall and src2pkg should both now support the scons and jam build systems.
Documents have been updated. Current version number is 0.9.8 and the original post has been edited with that number. The link is to the directory where the latest package is located.

Hello, I am not sure if this is the right place to a newbish question, but I will take the risk, begging your excuse.

My question concerns the practical usage of src2pkg. First, what is the difference between passing the argument -p=/opt/foo and the argument -e=--prefix=/opt/foo? In other words, what is the difference between package installation prefix and and the --prefix= passed to configure? Moreover, it seems to me that there is no obvious way of overriding the default --prefix=/usr, passed to configure. So my second question is whether there is some way to pass another --prefix to configure? There are some packages that are integrated with kde, that need --prefix=/opt/kde, instead of --prefix=/usr, like k3b, for example.

Thank you very much for your attention.
Regards,
Martin

-p is what is passed into ./configure as the --prefix. Doing it the other way may cause confusion to ./configure, since you are specifying two prefixes.

Yes, always use -p= to pass the prefix instead of -e=. If you give it in EXTRA_CONFIGS then you are passing 2 prefixes.
When the configure line gets run it looks like this:

$CONFIG_COMMAND --prefix=$PRE_FIX $STD_CONFIGS $EXTRA_CONFIGS

I see. And why does trackinstall as well have the -p optional argument? trackinstall is run after configure, so the --prefix to configure has already been passed. Does passing -p to trackinstall override what has already been passed as prefix to configure?

That's an oversight sort of. I was working on getting all the syntax the same in both programs and still haven't decided which options to include or leave out. I did some copy-paste between the two progs and there you have it.
It does bring up the question of being able to overide what was already passed to configure. Currently that doesn't work and I'm not sure I can make that possible. But, I'll work on it and see.
I've still been doing *lots* of changes the last few days tightening things up, so I appreciate your comments and questions.
Any of you have other options you'd like to see included? I'm thinking of dropping the
options for making non-standard packages from both. I mean the options for removing locale files, optimizing for size, etc. The thing is I only want to include the most useful options without having too many. The use of special options is best done with a PkgBuild/TrackBuild script any way, so you have a record of it.

tuxdev, have you tried the trackinstall -P for your SVN builds? Are you still able to test a jam build and scons?

I would suggest an option of creating the ready package in a specified directory, passed as argument. Currently we have the option of choosing between the current, home and /tmp directories. It would be more convenient to me if I could supply a directory I wish for the ready package.

Thank you for clarifying things.
Regards,
Martin

Actually this is possible with either src2pkg, trackinstall or when you run most PkgBuild scripts. By giving the argument from the command-line before calling the program or script:
PKG_DEST_DIR="/absolute/path/to/subdir" trackinstall (or src2pkg)
For a script:
PKG_DEST_DIR="/absolute/path/to/subdir" sh ./*.PkgBuild (or TrackBuild or other name)

PKG_DEST_DIR should be a directory where you have write permission! Notice that I purposely limited the choices and the options are not included in src2pkg. That's because of the havoc you can have if you are not careful where you work. I only made it possible to use $HOME as PKG_DEST_DIR for trackinstall at first.

I personally like to use $CWD for PKG_DEST_DIR as well as SRC_BUILDS_DIR, PKG_BUILDS_DIR.
This means that everything gets built in the current directory. This works easily with the standard SlackBuild layout. The script or program is called where the source tarball or a link to it is located. The build directories for the source and package tree also get made there. It's a bit easier to debug your package that way. If you want to keep all your tarballs in one directory, just use a link in the current dir.

You can also set it up like RPM and create /usr/src/pkgbuild/SOURCES ...BUILDS or whatever. Then set the values to those directroies in your /etc/pkgbuild/pkgbuild.conf file.

PKG_DEST_DIR is the safest one of these to change since we don't run any sort of rm -rf there.

PkgBuild used to default to working in the current directory until some one whacked their system by using /usr/share as SRC_DIR or something like that. I gave in to my own better judgement and went to the default use of /tmp for the working directories. That's the slack default anyway. I wrote in 2 huge blocks of code which double-check the main directory variables to make sure someone hasn't passed '/' as SRC_DIR or other made some other easy mistake. It would have been easier just hard code it all, but I use this myself and I like it to be flexible.

Note that you always need to have write privileges in the current directory because that's where logfiles, installwatch files, slack-desc, get created.

BTW - I've been looking at the -p option more today. I had hoped to do what you mentioned. But it looks a bit difficult. The thing is you can never tell what the Makefile is gonna do. Some have no DESTDIR support at all, or worse, partial support. Others use DEST or PREFIX or --prefix or still other or none at all. Some Makefiles use cp instead of install or do other things to tickle your system.

This is why I quit defaulting to using DESTDIR and started using installwatch. It will catch *every* thing, so we can always know what the command did and put things back the way they were right away.

I've looked at overriding the install prefix before, especially regarding stuff that installs to /usr/X11R6 and also as part of code to figure out what to do when there is no 'install:' rule in the Makfile. Line 680 FUNCTIONS-0.9.8 says "We could guess, but better not!".
The problem is that arbitrarily changing the directories won't work for all programs -some have the shared files/lib paths hardcoded. We'd probably have to recompile the program on installing it in order to be sure.
I've also thought about detecting stuff that would or should install to other than the given prefix -Makefiles that are hard-coded to /usr/local, or cases like you may have, where the default is /usr/local. Actually stuff compiled with --prefix=/usr/local is more 'portable' to /usr than stuff in /usr/X11R6. Stuff compiled for /opt probably shouldn't be moved around (maybe as whole-directory).

To do any of this would take quite a lot of code and maybe give dubious results since we'd just be guessing. Still this idea interests me.

Hello again!
I would like to ask another question about src2pkg. I apologise in advance if I sound stupid.
I need to know how to pass more than two arguments to the configure script? I tried passing several times the -e='blablabla' option, but it seems to only work for the first two arguments, the other additional arguments were not actually passed to the configure script. Actually, compiling a program recently I had to pass 4 arguments to configure, so I issued:
src2pkg -e='blabla1' -e='blabla2' -e='blabla3' -e='blabla4' foo.tar.gz

but it only seemed to pass the first two arguments.

Thank you very much for your attention.
Regards,
Martin

Try -e="blabla1 blabla2 blabla3 blabla4"

Alright folks, I've worked in the latest changes and requests. Made a lot of code changes. We're out of pre-1.0 numbers so please give the new version a good testing. Report any problems or make any requests as soon as possible so I can get everything worked in for 1.0.

See the ChangeLog for more details, but here are a few highlights:

Easily package the results of other installation routines, such as scripts which you run to install things like pre-compiled binary packages (opera, firefox, flash-player). This even works with interactive installation scripts. Using the -S option with src2pkg or trackinstall will by default use the command 'sh install.sh' but can also use any other command by passing the -i='some command(s)'.

automatic correction of names with capital letters.

ability to override NAME and VERSION when wanted or needed
added a -P switch to src2pkg and trackinstall which keeps PkgBuild from correcting the permissions in the sources -maybe necessary for SVN or CVS sources or if building a package from sources you compiled while running as a regular user.

Improved the handling of the install command line so that using something like this:
make DESTDIR=/some/dir install
will work, if it's supported by the Makefile. This will sometimes allow you to install to a different prefiy than what the sources were compiled.
Note that the -r option(INSTALL_RULE) is no longer used. Use the -i option (INSTALL_LINE) to pass the whole installation line you want run:
-i='make DESTDIR=/some/dir install'

Improved handling of sources which unpack with a different name than the tarball.

Added ability to prepend or append code (or both) to the doinst.sh

Thanks for the comments and suggestions!

Get the latest here:
http://distro.ibiblio.org/pub/linux/...9.9-i486-1.tgz