This new release has several minor fixes and improvements along with additional documentation. If you are using version-1.5 there isn't any big reason to update unless you just want to. I'm still trying to concentrate on improving the docs without making any big changes or adding features which might introduce bugs.
If you expeience any problems please report them to me promptly so I can fix them. Plus, I'm always interested in how you use the program and what you like or don't like, so keep the feedback coming.
Thanks to all who have been using and recommending src2pkg.
You can get the latest installable tgz package here:
http://distro.ibiblio.org/pub/linux/...nload/src2pkg/

If you are running under some other architecture, like x86_64, s390 or ppc, you'll need to build src2pkg from sources, by downloading the tar.bz2 archive, unpacking and running the included *.build script.

Thanks, gnashley, I've upgraded my Slack boxes to 1.6:-)
I like compiling programs from source, but having Slack packages that can be easily upgraded down the road is a very valuable feature of src2pkg.
src2pkg is an exceptional Slackware utility, folks:-)

I've been a longtime checkinstall user, but since the fstrans/installwatch bug, I started using src2pkg. It's simpler to use and gets the job done. I don't think I'll be going back to checkinstall.

I've upgraded also, one note, the man page still reads version 1.5. Not really important, just thought you'd want to know. Thank you, by the way for a very useful program. ;-)

Thanks for the reminder about the man-pages. It's useful to have them versioned, but then I forget sometimes. However, I usually change the version the first thing if any changes were made to the file. In this case I didn't make any changes to the man-pages as the usage and syntax have mostly settled into a pretty stable state.

Glad to be of service. ;-) I'm just the kind of geek that reads the man pages before I even open a program. ;-) Thank you for such a great program.

src2pkg closes a gap for me, as there are some more exotic programs for which there are noch Slackware packages available. src2pkg provides a way to manage and upgrade and remove such programs in a most reliable and convenient way.

If I had to vote for the most useful non-stock program for Slackware, I'd vote for src2pkg.

Many thanks, Gnashley!

gargamel

src2pkg closes a gap for me, as there are some more exotic programs for which there are noch Slackware packages available. src2pkg provides a way to manage and upgrade and remove such programs in a most reliable and convenient way.

If I had to vote for the most useful non-stock program for Slackware, I'd vote for src2pkg.

Many thanks, Gnashley!

gargamel

Great job, thank you gnashley!

I'm a long time user of checkinstall, but like mdg above, I'm wary of the fstrans/installwatch bug. I just downloaded and installed src2pkg yesterday and now I have a couple of questions.

How do you find out the configure options without first extracting the tarball? I mean, it seems redundant to extract the tarball and do a ./configure --help and find out your options then delete the directory and proceed with src2pkg.

Is there any way to make the src2pkg stop just after configure is done so that I could check and see if I want to proceed? I may want to check and see if I've configured everything the way I want to. Also, some software will go ahead and compile without some optional dependencies, i.e., mplayer would compile without Ogg Vorbis support, so I'd like the opportunity to check the configure output, i.e., mplayer would say something to the effect, "Ogg Vorbis support: Yes". It would be nice to have the option of having src2pkg pause after configure is complete with the ability to resume or stop the build.

Is there a way to have src2pkg upgrade an older package rather than just install a new version next to the old version?

Is there a way to specify placement of the completed package to a directory of your choice rather than $HOME or current directory? If so, is there a way to have src2pkg remove an older package after putting the new package in? In other words, if I use src2pkg to build and install foo-1.2.tgz and place the package in ~/packages and if there's a foo-1.0.tgz and foo-1.1.tgz there, delete foo-1.0.tgz, but keep foo-1.1.tgz in case I need to roll back to the last version?

I like the ability to build a package in non-verbose mode, but it would be nice to get some output if there's an error in the build so I don't have to waste time trying to figure out what went wrong. Is this possible?

Thanks in advance.

LocoMojo

Hello and thanks for trying src2pkg.
First, src2pkg is designed to be completely non-interactive. This is so that you can run it or src2pkg build scripts with a 'driving' script, like when you build a series of packages which depend on each other, without the need for input from the user. There are a very few source tarballs which require input during configuration. src2pkg allows you to handle these in verbose mode (-VV option).

By default, src2pkg doesn't supply any options to the configure script except the --prefix, which is automatically set to /usr unless you override it. This is done to increase the chances of successfully configuring. The thing is that any other default options break more builds than they fix. Even something simple like
"--with-gnu-ld" will fail more times than it will help.
src2pkg has no way of knowing if you *need* to pass arguments to configure in order to successfully configure/compile. The only thing I could do to get any closer to this would be to parse the configure information found in any rpm .spec file or debian 'rules' file which might be present in the tarball.

While src2pkg can configure, compile and create a package in a great majority of cases without any eytra options, I don't really expect you to just accept and install the package that way. You should always check the package contents to be sure that it is doing what you want or need. You should count on building a package at least a couple of times before getting it perfect -sometimes you will neeed to rebuild it dozens of times. srcpkg makes this all very simple though. You don't need to delete the old build directories or package as src2pkg always does this before starting a new build.

You can do a quick configure and compile test by using the -T option. Or you can test the whole process by using the -R and -A options. The -R option will 'replay' the running of 'configure' or 'make' if it fails during the build. The -A option will write a src2pkg script for the build, but only if the build succeeds.

I encourage you to use a src2pkg script for all builds, as it keeps a record of anything special about the build. When first generated, they are named *.srcpkg.auto. If you make changes you should rename it to just *.srcpkg. This provides an easy visual cue that something has been changed inside the script.

The easiest way to start a build is to first start by running src2pkg with the -N option which just writes a new generic src2pkg script for the named tarball and and a generic slack-desc file, unless one is already present beside the tarball.
Then start the first build with the command 'srcpkg -X'. That just runs the script you just created. If you want to turn on verbosity or other transient options you can do so, for example 'srcpkg -X -VV', so you can see the full output from configure, etc.
While src2pkg begins to work you can edit the new.slack-desc if wanted and change the name of it to simply slack-desc so it gets included in the package. Usually you can finish that before src2pkg get to the point in the build where it looks for it. You can also cd into the unpacked sources (the SRC_DIR) and manually run
'./configure --help' to find out about any options which may be needed or wanted. If something is needed, src2pkg will fail and you can add the options easily by generating a new script with the options included. Same for any extra options you want to pass. You can always stop the build with "CTRL+c" at any time. Then regenerate the src2pkg script with the new options to configure, for example
'--disable-gnome', by running "src2pkg -N -e='--disable-gnome' tarball.name". Use the up/down arrows for the shell hiatory to save so much typing. Ths will create a new script, by clobbering the old one.
Once you have added the new options, just run 'src2pkg -X' again to re-run the script. src2pkg will always start by removing the old source directory (SRC_DIR), the old package tree (PKG_DIR) and the old package that match the current NAME, VERSION, ARCH, BUILD, and SIG. (If you rebuild and change any of these the old dirs and package will not be deleted. This done on purpose because it allows you to try various options with separate builds -even building at the same time.)

src2pkg includes its' own code for installing packages(a mini installpkg). It does not include the possibility for 'upgradepkg'. It could, but probably will not. here'S why: One of my main dislikes of checkinstall was that it always installed the package to your system. So from the beginning I designed src2pkg to not do this. Ironically, the best way to accomplish this means that every build *does* get installed during the build, and then gets removed before the package is completed. The logic of how these steps go is pretty hard to follow, but basically, src2pkg tracks what happens when 'make install' is run using the installwatch library. It does not use DESTDIR and directly spams your / directory. This is done because DESTDIR and other such things like INSTALLROOT are not very dependable. Even 'make uninstall' can't be counted on! However, installwatch includes a feature which allows you to create backups of any file which will be overwritten. So src2pkg uses this feature to save the old copy of any file which is about to clobbered and then restores the original during the build. This is done nearly immediately and ldconfig is run repeatedly so that you can actually compile and package programs and libraries which are in use at the time. src2pkg uses a few statically-compiled programs(included) during this phase of the build to make sure that your system gets restored to its' original state. So, if you have built a newer version of something, it actually gets upgraded and then downgraded during the build!
The option to have src2pkg install the package to your system (src2pkg -I ...) is really meant to be used for builds that have already been tested and perfected. For instance, if you want to build GNOME or something like that where packages must be compiled and installed in a certain order. Using the -I option lets you create your own 'bootstrap' scripts. You can also use it for individual packages when you see that the package is okay. (Run src2pkg -X the first build, make any changes you want, then run 'src2pkg -X -I -W' to install the package and cleanup)


You can specify where you want to place finished packages by setting the PKG_DEST_DIR. If you want to permanently change the location, you should do this by editing the file /etc/src2pkg/src2pkg.conf. You can also do this on a case-by-case basis by running your src2pkg script like this:
PKG_DEST_DIR=/some/path sh progname.src2pkg

Another user suggested once that an option be included for changing the packahe location from the command-line, However, the location of the main working directories is really a delicate matter and should only be changed if you know what you are doing. The real problem is(can be) with changing the location where sources are unpacked and the package tree is created. Since src2pkg cleans up the old directories we must be very careful about which directories are used because
'rm -rf' is a very dangerous command. For this reason the defaults for these directories are under /tmp. src2pkg includes an exhaustive check of these variable values in case you specify some place dangerous. Please see the src2pkg.conf file for examples of how you can set up your build directories in a safe way that you like. (I do all my builds in a separate partition and like to have everything done in the current directory to avoid always browsing to /tmp and looking for the SRC_DIR and PKG_DIR. And I leave final packages in the current directory. But you can set this up to suit you -sorting packages into categors directories like Slackware, or keeping everything under one directory like RPM does.)

As mentioned above. src2pkg will only delete a package which matches the name, version, etc of the current build. Any other logic might destroy an older package which you want to keep.

About the verbosity, as mentioned you can run in QUIET mode and use the -R option to have src2pkg re-run the failed command. The -V option just shows some extra prompts which help in debugging or to show a little more info about what src2pkg is doing or has found. Using the -VV option lets you see all the ouput that you would expect from running the command normally, including 'configure', 'make', 'make install' and the ouput from 'makepkg' and 'installpkg'.

Hope this helps you to get the most from src2pkg. ( The name LocoMojo makes me wonder... are you from Odessa, Texas?)

Hello gnashley,

Thanks for your very informative reply.

After posting here yesterday I realized I spoke too soon as I discovered the src2pkg.conf options (I don't know how I missed it). Anyway, tweaking that file solved most of my issues perfectly.

I also tinkered with src2pkg and all of its options and now I understand better how to utilize src2pkg at its full potential. I really like the -N option so that I can enter a description for the slack-desc file and then a simple -X to proceed.

I don't much care for the fact that I need to extract the tarball to find out my configure options before getting src2pkg to do its thing, but that's not too much of a big deal. It would be nice though if src2pkg could pause after extraction then issue a ./configure --help command and then allow me to enter configure options.

The only thing left was my desire for a pause in the script after configure did its thing. It was easy enough to hack the FUNCTIONS file for that. Now src2pkg pauses for me and gives me the opportunity to review the configure output and then decide whether I want to proceed with the build. All is right with the world now

Thanks for a great script, you've just acquired a new src2pkg user.

By the way, no...I am not from Odessa, Texas. In fact, I've never even been there. I've been using the LocoMojo nick since I first got on the internet in the early nineties. Don't ask me why I use that nick, I don't have a clue

Cheers!

LocoMojo

Update: Just hacked FUNCTIONS again and now I can get and input my config options before configuration without having to manually extract the tarball for config options.

Send me diffs or a copy of your FUNCTIONS file <amigo@ibiblio.org>. I'll consider including such features and at any rate am interested in what you are doing. Pretty good that you were able to figure out where and how to hack it at all -lotta code going all over the place. Hope the comments helped. About Odessa, they call their football team Mojo.

Just sent it your way. Don't laugh when you see my hacks

Your comments helped immensely. Without them, I would have been lost.

They call their football team 'Mojo' in Odessa? Is that right? Heh, cool!

Cheers.

LocoMojo (A NY Giants fan)

Many thanks gnashly,

Perhaps you will recall me from "The Magic Package Maker Comes of Age" earlier this year. I would like to resume where I left off. The packages I did succeed in making after much help have worked fine. I have removed version 1.0 and installed 1.6. The package that I am trying to build has also increased a couple of notches. But I would like to make a script.


Never got that one in version 1.0. Have tried commas brackets and the like without success.

Having overcome above problem the next will be selecting the correct compiler like a Makefile does. This is where I left off before.


John