The new release of src2pkg is now available. Highlights of this release are the addition of support for sources which use 'cmake' for configuration and a new interactive mode -something I didn't really expect to do. But after receiving a suggestion from LocoMojo and a patch which demonstarted the desired behaviour, I decided to implement it as a non-default option. Three small chunks of code can be activated to ask the user for input during package creation, when applicable. Each can be activated separately or all three at once by editing the /etc/src2pkg/src2pkg.conf file, or all three can be activated from the src2pkg/trackinstall command-line with the '-Q' option (for Query).

The first interactive step is during configuration of the sources. If enabled, src2pkg will run './configure --help' to show the available options and pause to allow you to input the desired options to configure.

The second interactive step is after configuration. If successful, src2pkg will ask you if you want to continue with compiling and creating the package.

The third interactive step is during creation of the deafult slack-desc file. src2pkg will pause and allow you to enter a one-line description for the package. We don't do the whole 9 lines or more like checkinstall does -that's one of the things I disliked most about checkinstall.

Anyway, for those who miss being interrupted during package creation, this should make you feel more at home. This behaviour is useful for increasing the chances of creating a more complete, working package with a single running of src2pkg. The interactive option is off by default, though, as it may encourage the user to build a package with extra options and not keep a script of the build.

The support for sources which use cmake is not thoroughly tested as I don't really know of many sources which require cmake. If you experience problems please let me know so I can fix it.

This adds the new options to the src2pkg.conf file, so be sure to update your src2pkg.conf file and read/edit it if you want to use the interactive features by default.

This version includes several minor bug-fixes and improvements for POSIX conformance. It also includes my patched version of the installwatch libraries and installs the installwatch executable to /usr/bin if you want to use it separately. It also brings back the 'tracklist' utility, which is a small wrapper for using installwatch non-intrusively. It will track and list the files and directories created by most any command -basically just like using installwatch, except that it parses the logfile to produce a clean list which is readable.

You can get the latest package or sources, or see the full ChangeLog in the usual place:
http://distro.ibiblio.org/pub/linux/...nload/src2pkg/

Thank you, gnashley for all of your hard work for Slackers everywhere:-) Just upgraded to 1.7:-)

Great, thank you.

Hello Gnashley,

Just downloaded and tried src2pkg-1.7 and it works great. I really like the -Q option because with some sources I know that I won't have any extra config options to pass to configure so I can just go straight through without any interactivity. With other sources, however, I may want to pass some extra config options and it's easy enough to do this simply by passing the -Q option to src2pkg. I really think that the query feature, especially the ability to enable/disable it on the fly, significantly enhances src2pkg.

Great job!

Haven't tried it out with cmake or scons yet, but when I do I'll come back and let you know how that goes.

Thanks so very much for being receptive to your users' suggestions or ideas!

Have a good one!

LocoMojo

FWIW cmake built packages that I've made recently include kdesvn, kaffeine, khtml2png

CMake support? That's awesome, since I've been getting SuperTux to move to that build system.

I have a suggestion to tweak the interactive part: use $EDITOR to change slack-desc. That should alleviate almost all of the problems with checkinstall's approach.

Great work! Getting better and better

Just downloaded src2pkg for the first time and had a quick question. Whenever I used to make packages with checkinstall, I would unpack the archive, read the INSTALL file to see if any non-standard build process was required, then ./configure, make, checkinstall. It looks like src2pkg unpacks and builds the package automatically, without giving any chance to read the README or INSTALL files to see if extra options are required. If I want to unpack the archive myself, then let src2pkg take care of the process from there, what options do I use? Or do I need to let src2pkg unpack the original package again?

Also, just a suggestion... It would be great if src2pkg had even the most basic text-only website with an introduction and maybe a basic tutorial. There seems to be a lot of partial documentation in different places, but I haven't been able to find a tutorial-like introduction.

Thanks again for all your work on src2pkg!

src2pkg doesn't really have an option to just unpack the archive, but you can use the -T (test) option which will attempt to unpack, configure and compile and then exit without trying to install. That gives you a chance to read the README file. Also the new -Q option will unpack and then run './configure --help' in the sources and give you a chance to enter options. It then proceeds to attempt configuration with those options and stops before compiling to ask for confirmation -you can go ahead from there or exit. If configuration, compiling or installation doesn't succeed it will exit anyway.

Sorry about the documentation. There have been tutorials in the past, but they get outdated. I have started over several times with the docs -as new featrures have been added the old docs don't apply. Beacuse src2pkg has quite a few features it is quite a chore to write complete documentation. I'm going to start over again and I'm thinking about creating a webpage for it -another thing I really dislike doing, but seems to be more and more necessary.

Thanks for the explanation. If there's no way to extract the package yourself and let src2pkg take over the process from there, is there a way to use src2pkg like checkinstall worked (or maybe trackinstall is what does that)? In other words, is there a way to unpack the package yourself, manually do ./configure and make, and then tell src2pkg to run make install, track modifications, and install the slackpkg?

You can use "trackinstall", it's intended as a direct replacement for checkinstall. Although, you should check out version 1.8, it's very cool and looks like it has the pause-and-look features you want now. I've been planning on writing a repository manager based on src2pkg, it is way easier now that I don't have to be root to do everything.

Yes, jrdioko, you can use it just like chackinstall. After compiling, just cd into the sources and run 'trackinstall -I'
The '-I' option tells it to really install the package.

Still, I think the '-Q' option may be what you are looking for. What it does is stop before configuring the sources and run './configure --help' which lets you see what options are available. Then you can type in the options you want and hit ENTER to proceed using those options.

The -Q option sounds almost like what I want, but what I'm really interested in looking at before compilation is the INSTALL file. I usually don't really care about the ./configure options unless the package maintainer specifically mentions ones to keep in mind in the INSTALL file.

Some INSTALL files I have seen tell you to use gmake instead of make, "make install-strip" instead of "make install", etc. Others describe dependencies that you need to build and install first. I'm really looking for a way to extract the package, have src2pkg stop and let me read the INSTALL file, consider options, install dependencies, edit the Makefile, etc.--then continue with compiling and installing. And I guess it sounds like trackinstall is the way to accomplish that.

Thanks again for your help.

src2pkg automaically strips all bins and libs unless you tell it not to. Most INSTALL files are just a generic file which is part of the autoconf package(when the author sets up sources to use autoconf the INSTALL file is created, among others.) Usually, the README files have more specific inforation than the INSTALL file on what the specific needs are. Either way, src2pkg obviously can't make heads or tails of such unformatted information -it can't read the README for you and figure out what needs to be done.

While you could always manually unpack, configure and compile, then use 'trackinstall', it would really be better to use src2pkg for all the steps. If you do pass extra options to configure or change the commmands used to compile or install then src2pkg will keep a record of those changes for you. That way, the next time you compile the software you don't have to try and remember what special steps were needed.

I also have a good habit of looking through the sources and the package content before creating the final package. What I usually do is just start src2pkg with the -A option, or use the -T option if you like. Then while it is working I go in to the sources and look around and read whatever I need to. If I see something that really needs to be corrected I just stop the build by pressing CTRL+C. Then I make whatever changes are needed and restart the build. Since src2pkg cleans up all temporary files before starting again this makes it super easy. For instance If I see that I need to add options to configure I just add them to the command line. If you use the -T option the build will stop anyway after compiling.
Since re-building is just a matter of issuing a single command it is ceratinly more easy than manually removing and then unpacking again, configuring manually etc.

If always keep a script of the builds, so I usually just start by using the -A option which writes the script when and if the build is successful. This doesn't always mean that the first build creates the final package. If I see that I need to add options or change something, I re-create the script with the new options and use -N to re-write the script. Then I re-run it using src2pkg -X

I have never found a single program among thousands that needed to use the gmake command. On Slackware, gmake is a link to make so when you run make you are already running gmake.

Anyway, the point is that you should just let src2pkg take care of all those repetitive commands -especially the pre- and post-build stuff. I often start a build by using the -N option to create a script. then I start the first build with 'src2pkg -X' and then whil it starts I go into the sources and find some description info and edit the slack-desc file and save it so the changes already get included (unless the package is so small that src2pkg finishes before I do.)
Don't get me wrong, I ceratinly believe in the value of looking around in the sources and even more so in looking around in the final package content. But that doesn't mean that you have to revert to doing half the work manually. Just don't be so hesitant to build more than once.

The point of src2pkg is not to get everything right the first time -though there are some things which it must get 'right enough' in case you do only build once. The point is to reduce the amount of repetitive commands and, ideally, to keep a record of the build so that you can easily repeat it -five minutes later or five months later.

I've kept interactive functionality to a minimum to make sure that builds are repeatable. Repeatability is the whole point of having a script.

Thanks again for a detailed reply. Maybe I just need to rethink how the whole building process works. I'm still running into problems though with the few packages I'm trying to install. The first is LilyPond (http://lilypond.org/web/install/) which needs to be installed by running a shell script installer. With checkinstall, I would have typed "checkinstall sh lilypond-xxx.sh". I can't figure out how to get either src2pkg or trackinstall to install it correctly, though. Any suggestions?

Also, just a follow-up on my website suggestion. I understand that it's a lot of work to get a website up and running, but how about starting a SourceForge project? That would create a central site with an organized way to post bug reports, feature requests, support requests, etc., rather than adding those things to the end of LQ threads like this.