'src2pkg' Converts sources to installable packages
 

src2pkg is a new command-line front-end for PkgBuild which makes building sources even easier. It will also write a script for you for repeat builds or modifications.

See documentation here:
http://distro.ibiblio.org/pub/linux/...migo-PkgBuild/

src2pkg is included in the pkgbuild-0.9.1-noarch.tgz package. be sure you have installwatch installed. You can also get that from my site if you don't have it:
http://distro.ibiblio.org/pub/linux/...6.3-i486-1.tgz

Nothing against your scripts and such, gnashley, but...

For me, it's much easier, and more reliable, toThat way, I know that my system is compatable and I know the errors.

Another layer of complexity/hiding the process is NOT what I have Slackware for.
If I wanted handholding and 'protection' from the nasty processes, I'd opt for Ubantu or Fedora.

Others may find it useful, but to install two or three new packages to just install source? Why? After checkinstall is done, I have my own package for my own system. And it ALWAYS works.

Sorry, but not for me.

But keep up the good work. Others may like it/need it. But it's not for my personal vision of Slackware.

Just turn on the verbosity and you can see it all.
Study the documents and you'll see why this is much more reliable and safer than checkinstall, which can lose files on your system and overwrite existing files.

src2pkg myprogram.tar.bz2 does exactly the same thing as running chekinstall, except that it also unpacks the sources and creates the directories, etc. Add the -w switch and all temporary files will be removed.

Plus, PkgBuild corrects many common errors made by by faulty or incomplete install rules.
I understand that it's not for everybody. Not everybody gets a kick out of perfecting a build and build script. I still do, but I don't have to write a lot of extra lines anymore which are tedious and repetitive.
If you have 2 packages which will compile on your system with just
./configure --prefix=/usr
make
make install (or checkinstall)
and you write build scritps for each of them, you'll find that they are 50-100 lines long and the only difference between the 2 scripts is where the package name, version, arch or build number are different.
PkgBuild uses this fact as it's pretext. A generic PkgBuild script for the above packages only needs to specify those differences, source the PkgBuild functions and 'do it all'.
Endlessly rewriting the same lines for different packages makes no sense to me. Last weekend I added over 30 packages to my site. Have a look at any of them and find what's wrong with it and tell me, please. Coding 30 scripts by hand to do that might take weeks.
Using PkgBuild lets me concentrate on the finer details of getting a program working just right, or getting it to compile at all. It's flexible enough to let me build nearly any kind of package. And the addition of src2pkg makes it even easier to start a well-documented and repeatable build, even for those who can't write scripts at all.

Anyone who has tried checkinstall should definitely try src2pkg. And if you've used
checkinstall lately, look in /usr/man/man1... See any uncompressed man-pages there? PkgBuild won't do that.

Quoted rom the checkinstall script:
# Now we get the TRUE list of files from the directory listing (kind of)
# of the BUILD_DIR. This is the true one simply because THESE are the files
# that will actually get packaged.

While your method is EASIER, it is not always reliable. checkinstall can and does fail. Also, you have now added one new package. To make sure checkinstall does it's job correctly, you might want to try a tool like installwatch, but now you have installed "two or three new packages just to install source".

To get around the possible errors of checkinstall, you can install 0 new packages and just write your own SlackBuild scripts. But now, you have a RELIABLE solution that is no longer easy.

Gnashley's solution is very nice, in that it is both easy and reliable.

If making good packages was always as easy as just using checkinstall, then there would be no need for third-party packages. As an example, notice that all official SlackBuild scripts are more than the above three lines of code.

***EDIT***
Gnashley also types much faster than me. :)

Actually developing this has turned my own thinking around about system safety and keeping track of installed files. I was including the use of installwatch as an option. When I saw that DESTDIR was not reliable nearly half the time (when supposedly supported), I made it the only installation method. I do plan to put back an option for using DESTDIR when wanted.

And about installing various packages -src2pkg is part of the pkgbuild package. I don't include the installwatch libraries because you may have them already installed. I've considered including them, but then others will complain that it overwrites installed files, etc.

checkinstall uses installwatch to generate a list of files installed by make install, but then knowingly fouls up the list and loses files. Plus checkinstall installs the package by default. At first, I wanted to avoid this and used DESTDIR.
My tests and checks using installwatch really shocked me! So I took advantage of the installwatch 'backup' facility to backup and restore any files overwritten. checkinstall only offers to create a tgz backup of overwritten files. If something critical gets overwritten, you may not be able to repair it easily.

One user did report problems using PkgBuild with checkinstall installed on his system, because of installwatch incompatibility. On my site you can find the stable version and a development version of installwatch in binary or source packages.

I used to use checkinstall exactly as cwwilson mentions. But then a few months later when I wanted to rebuild the package, it was always "Now what was it I did to get that to compile?" The very first goal of PkgBuild was to enforce the writing of scripts. Now, src2pkg will write some of them for you. And maybe soon it'll even write a self-contained SlackBuild for you, so you can use the build script without having PkgBuild installed.

Nice piece of work gnashley. I'm used to create own Pat's like SlackBuild scripts without a hassle. For safety reasons all build scripts _have_ to work properly running under a non-root user, no file outside his home dir, /tmp and /var/{tmp,lock} may be touched. I've a very good experience with fakeroot tool from debian project, at a package creating you don't need to use root account at all.

I'll check this out when I get a chance, but to be honest, I don't see any problems with my current way of doing things.

I have no doubt that checkinstall will build the occasional broken package, just like I have no doubt that every piece of software will fail at some point. My only concern is if those failures and bugs effect my use of the software, and so far it hasn't with checkinstall. I have a package repository I keep on my network for all of my Slackware machines, and right now I have over 100 packages I have built, about 90% of them being done with checkinstall (the others with makepkg), and I can't say there has ever been a problem.

Not that I don't see an advantage of what you are doing here. In fact, I was writing some scripts a few months ago to do pretty much what you are talking about, decompressing tarballs, configure/make them, and then build a package and put it on my package server.

But after messing with it, I realized that while it would save me all the repetitive typing like you mentioned, I just didn't feel comfortable having the packages being built autonomously. If I wanted the machine to do everything for me, I would use Windows. I want to be involved, I want to check each step, that is why I am using Slackware in the first place.

While everyone else seems happy with their way of doing things - I've encountered a few little checkinstall niggles. I only use checkinstall as a way of removing packages and keeping track of what's installed, so if it doesn't do that job, then it's time to look to the future!

I too get frustrated with trying to remember how to compile something, and the ideal tool for me would be logging the ./configure line in the description, just so i could remember what i did! While I enjoy checking each step, rarely do I simply do a single package install now - it's usually an upgrade of one of the gtk-based apps (inkscape, dia, audacious) which means upgrading gtk ... and you all know how much fun that is ;)

The frustration is doubled since I don't use Slackware on many boxes these days, but Slamd64 - so many little extra bits are frequently required to get the source to compile nicely. A common line for me these days is:

LDFLAGS="-L/usr/lib64" ./configure --prefix=/usr --libdir=/usr/lib64

And that's on a good day when i don't have to hack the makefiles. Don't even talk to me about compiling Qt apps!

A couple of queries, if you don't mind?

1. If I understand correctly, we'll end up with a script that logs my configure line, as well as building the package from said line? (w00t!)
2. Where would you advise changing the "default" ./configure line for us bi-arch users?
3. Is there a possibility of having things autoinstalled and saved in default repository locations? I've gotten quite used to checkinstall doing that for me - once ./configure && make is completed I figure that it's hard to go wrong at "make install" (although your System-Safety.txt has given me a different perspective! I had no idea about those man pages!). I will happily hack the script or write a wrapper to do what i want, but, would appreciate your view on that =)

Clearly 3. is my own personal wish and I can understand that it probably doesn't fit in with what you're trying to do =)

Good work, thanks!
- Piete.

piete...

I was playing with this on Slamd64 last night... I just installed Slamd64 from current, so I'm still getting used to where things are located on a 64 bit system.

The configure options go in the New.PkgBuild file in the line for "EXTRA CONFIGS". I think you'll also want to change the DEFINES file in /usr/libexec/pkgbuild so that the -march and -mcpu options are "k8". I'm still having trouble with installwatch trying to find installwatch.so in /usr/local/lib, but the odds are that's my own fault. (Like I said, I'm still learning where to put things on a 64 bit system...)

My suggestion would be to read the first couple pages of the Quick.HOWTO and then just jump in. IMHO, PkgBuild has a lot of advantages over checkinstall.

Ahh, Jim, thanks! I had a brief squint at some of the files, but not hacked at anything yet. Presumably some auto-arch detection (ARCH=${ARCH:-i486} plus the case statement) could be used up there somewhere to give the script some flexibility (I may want to build a 32-bit binary on the 64bit system) ... I'll investigate that.

Installwatch has always disappeared into /usr/local/lib for me when i've installed checkinstall into the system. I'm lazy and figured that i'd never have reason for a 32-bit installwatch library, so just left it there - it seems happy enough, although i realise it's in the wrong place.

Thanks again, I look forward to some further investigation =)
- Piete

I've used the earlier vesrion to compile around 100 packahes for PPC. I only had to change the ARCH and STD_FLAGS variables. And I had to change a few scripts where I had hard-coded 'i486' in.

Take note that all these options can be passed to PkgBuild or src2pkg 'from above'. If you want to use the same scripts under different architectures, use an alternate config file, or a group-build script.
You can also create a custom template for stuff like this.

CONFIG_COMMAND="LDFLAGS="-L/usr/lib64" ./configure"
EXTRA_CONFIGS="--libdir=/usr/lib64"
should be all you need other than the changes mentioned for -mcpu, etc.

I'd recommend uninstalling checkinstall and then installing installwatch from source. It may not be obvious, but you can't track installwatch with installwatch, so the PkgBuild script for installwatch doesn't need installwatch installed. So, install PkgBuild-0.9.1 and then build installwatch and install that and you should be ready for the rest.

Installation can be done with REALLY_INSTALL="YES"

For instance, when you have a package or group of packages that you know are building correctly, you can quietly compile them, clean up and install them as you go like this:

REALLY_INSTALL="YES" CLEANUP="ALL" ./my.PkgBuild

Notice that nearly all veariables are set up like this so that you can override them from the command line as above, or the same way but from within a group-build script.
The idea is that you should only put an option in the PkgBuild script if it will always be used for that package.
Auto ARCH detection is discussed in the docs. I plan to do that as an option, however my crude manual method may give more consistent results.

Hi Gnashley

I don't know what happened, but src2pkg failed on an install

My system began to behave strangely so I rebooted. When everything came back up I found that my /home/samac directory was owned by root:root.

Not an ideal situation to be in. I only tried to install 2 packages from source prboom and xfreecell,both failed.

I think I will stick to the old fashioned method, which is a shame as the idea is very good and when it works for all source packages it will be a useful solution.

Will now remove pkgbuild and installwatch.

Samac

Ouch! That can't be pleasant.

But to be fair to gnashley, if you read the Quick.HOWTO the first two steps are supposed to be:
1. Log in as 'root'.
2. Create a new directory where you have write permissions.

Nothing will work for every program, so it's important what happens when a build fails. Early versions of PkgBuild had no error checking whatsoever and would always build a package.
After version 0.4 I began putting in code to exit on failure, but with prompts or cues that try to be helpful. They also serve as 'precursors' to more complex code which will handle exits, step-by-step script writing, etc. However, the hard exits are still quite limited. I do this on purpose to allow for 'sloppy' scripting by the user, for allowing steps to be skipped over and for building unusual stuff like noarch packages.
For example if configure_source exited hard because there is no configure script, then the step would always have to be commented out for simple sources that don't use configure.
Also, I always planned to use the functions as src2pkg does with 'control layer' above the functions which handle errors and execution in more complex ways, like resuming builds, or testing a build by running just part of the functions. Version 0.9.1 has a few changes from 0.9 which go toward this, such as not including the 'exit 0' line at the end of the script and not using ';' semi-colons after each instruction. This simply opens up the exit status of each build script allowing for further processing.

The hard exits which are coded into the functions will be replaced with more intelligent code which will allow 'src2pkg' or other programs to work by signalling the exit status of each step and a final build status. Step-by-step signals can be used for testing and for complex auto-scripting. The final build status will allow for better group and chain build handling. Currently, if you try use a group-build script and one build function fails you get a hard exit.

piete, in order to use the same scripts for differents arch's, pass those flags from above someway -by using 2 different config files or maybe with a wrapper like this:

#!/bin/bash
# ARCH64

LDFLAGS="-L/usr/lib64"
EXTRA_CONFIGS="--libdir=/usr/lib64"

exec "$@"

Save that as ARCH64, make executable and place in /usr/local/bin. Then when you want to compile with those options run the PkgBuild script like this:

ARCH64 ./*.PkgBuild

You might also have a look in DEFINES at the way SAVE_SPACE is used. You can create yourself a profile line in DEFINES like this:

if [[ $ARCH64 = "YES" ]] ; then
LDFLAGS="-L/usr/lib64"
EXTRA_CONFIGS="--libdir=/usr/lib64"
fi

Of course, you may need to include the ARCH and STD_FLAGS stuff here as well, to avoid using different config files.

Also you can have all the packages laid anywhwre you like by passing the PACKAGE_DEST_DIR variable. This is set to equal $CWD by default. I actually wrote support for group names into the name parsing, but I don't recommend using it and the code will be removed. This is handled by using a group-build script similar to above, which sets up any common variables for packages to be built.

I'm very open to suggestions and welcome the feedback.

You're correct very nasty, but whilst I understand Gnashley's reasons for hard failure, I do have to make this point.

Gnashley, please make the documentation relevant. I did look at the Quick.HOWTO and at no point does it mention src2pkg, so I looked at the options e.g. -l for loud (normally that would be -v for verbose). We cannot give your software a fair test if we are not aware of it's idiosyncracies.

Please take this as it is meant, constructively, I wouldn't be using such a full, rich, stable and satisfying operating system if it wasn't for developers like you, and the thousands of others.

Samac