The 'Magic Package Maker' comes of age and changes its' name
 

Finally PkgBuild has reached version 1.0 and celebrates by changing its' name to 'src2pkg' (There was already a program called pkgbuild)

src2pkg adds several new features including:
- handle source RPM packages directly -no need to convert to tar.gz or tar.bz2 format before building
- handle conversion of 'foreign' binary packages such as '.rpm' and Debian '.deb' archives.

The simple command 'src2pkg tarball-name' will succesfully build an amazing variety of source types -maybe even some packages that you haven't been able to compile manually!

- added easy-to-use options for installing the package once created and for saving backups of any files overwritten on your system during building of the package.

I've found that src2pkg will successfully build nearly any source package you throw at it, if the sources can indeed be compiled on your system. Of course, making the 'perfect' package may still require a few extra lines in your build script or that extra options be given on the command-line. But most of the scripts I wrote for use with early versions of PkgBuild which included lines for unusual circumstances are now obsolete.

If you find some source package that src2pkg can't properly unpack, build and package, I'd really like to hear about it -I'm having trouble finding sources that 'challenge' it anymore, so let me know what doesn't work.(SRPM's which contain more than one tarball may give problems occassionally -but it will even build some stuff that has a different name inside the tarball)

src2pkg handles nearly any autoconf source, even incomplete or CVS sources and ones that use GNUmakefiles; simple sources with just a Makefile; imake-type sources; sources which use scons or jam instead of make

Package building has never been this easy, or more accurate -no more excuses for not having your own package repository for your favorite software. Porting other build scripts or rpm .spec files is really easy -usually all you need to get from them are the extra options passed to configure -takes just afew seconds to add that to a new src2pkg build script which src2pkg will generate for you, before or after building your package.

Decompression of .rpm and .deb archives in handled by the excellent proogram disrpm, which is included and installed to /usr/bin so you can use it apart from src2pkg. It actually succeeds in unpacking many rpm's where rpm2tgz and rpm2cpio fail -now you don't need rpm installed anymore to handle them, plus it also works for debian packages.

The latest package is available here:
http://distro.ibiblio.org/pub/linux/...1.0-i486-1.tgz
Future versions will be located in the same directory, so you might bookmark the page for future reference.

Awesome! May i be near the top to congratulate you!

Finally time to uninstall checkinstall =D

May I ask, what is your recommended directory structure for building and storing sources?

I started with just a /home/user/src directory for the tarballs, but found that messy. Now i've moved to a ~/tarball ~/src structure, one for downloading into and one for building in ... still messy. On top of this i've got a /home/packagebuild/packages directory for storing the built packages.

Many thanks and good work!

- Piete.

Have you tried compiling noteedit from source?
I would consider this to be the biggest challenge that I have come across, with layered dependencies, config command line options and a final python script to complete the install.
LOL ;)

Piete, you can set up a build area rpm-style by making directories under /usr/src or wherever. One directory for sources, one for packages and one for all the builds. Then edit your src2pkg.conf file to point to these directories.
For example:
cd /usr/src
mkdir sources packages builds scripts
Then edit your scr2pkg.conf like this:
SOURCES_DIR="/usr/src/sources"
SRC_BUILDS_DIR="/usr/src/builds"
PKG_BUILDS_DIR="/usr/src/builds"
PKG_DEST_DIR="/usr/src/packages"
BACKUP_DIR="/usr/src/builds"

Then under the directory scripts set up a separate directory for each package. This is where you keep your scripts, patches and other material used by the build, if needed.

This is just an example. Note that you don't really have to assign SOURCES_DIR to keep all your tarballs in one place. You can always put them anywhere and just create a link to them from the individual directory where the build script is. Hard-coded paths also work, even if it isn't the same as SOURCES_DIR. To make this work you give SOURCE=/path/to/tarball instead of SOURCE_NAME=tarball

Another thing to consider when editing src2pkg.conf: The options as shown above are not easy to override. If you still want to be able to override the options when needed, write them like this:

! [[ $SOURCES_DIR ]] && SOURCES_DIR="/usr/src/sources"
! [[ $SRC_BUILDS_DIR ]] && SRC_BUILDS_DIR="/usr/src/builds"
! [[ $PKG_BUILDS_DIR ]] && PKG_BUILDS_DIR="/usr/src/builds"
! [[ $PKG_DEST_DIR ]] && PKG_DEST_DIR="/usr/src/packages"
! [[ $BACKUP_DIR ]] && BACKUP_DIR="/usr/src/builds"

This way lets you still override from the command-line when needed.
Hope this helps you.

Congratulations and many thanks to you gnashley, awesome work!

Slackware and the community here rock!!!

To allend: I'm compiling noteedit at the moment. It was a little tricky to get going at first, mostly because I don't usually have KDE, QT, arts and python installed. Once I installed them (plus kdemultimedia and attr and acl) I was able to progress okay.
First I had to install tse3 which was straightforward except the sources need to be patched to compile with gcc-3.4 and for alsa support.
There are two slightly odd things about noteedit. First having to export KDEDIR and QTDIR before configuring and compiling. Plus, for some reason kdeguitar_excerpt fails to compile completely when compiled from the top source directory.

However this was easily solved by a just doing the confiure_source and compile_source steps manually. I'll upload the sources, patches, build scripts and packages a little later, but meanwhile this is all it really took to get a good package:

Run 'src2pkg -N noteedit-2.8.1.tar.gz' tzo produce an initial script. Then edit
it as below:

# configure_source
export QTDIR=/usr/lib/qt
export KDEDIR=/opt/kde
cd $SRC_DIR && ./configure
# compile_source
cd $SRC_DIR/kguitar_excerpt && make
# now compile the rest
cd $SRC_DIR && make

Voila! This makes a good example of how little intervention is needed even in drastic cases. These are exactly the steps which you will most often need to override, and you only have to substitue the same commands you'd give when compiling manually, except you need to use the $SRC_DIR variable.

gnashley

If my daughter approves then your a star!

Okay, allend, you'll find all the build stuff and packages for tse3 and noteedit under this directory:
http://distro.ibiblio.org/pub/linux/.../Extra/KDE-QT/
Thanks for the suggestion. Hope your daughter is thrilled, but pianissimo...

Did I somewhere hear someone said that they sometimes unpack or do something with a .deb package just so as to trace or answer the question "what dependencies does a package have?"

Anyways, given "if that, the above" then I'm wondering if I could use this src2pkg on a .deb to get a dependency list and then to build the pkg *and* also build each of its dependency for Slackware 11.0.

(I've been to sourceforge and I'm unable to decipher the lingo there in order for me to understand exactly what I need in the way of dependencies for liferea which is an rss client)

IOW I'd like to have a liferea package and its dependency packages (few gnome libraries) for Slackware 11.0 (I'd want to run liferea from within KDE)

Too many probs with akregator rss client on KDE (maybe doesn't like my DSL modem or etc. but have to reload too too many times then still misses retrieving a few.

liferea on CentOS 4.4 does not do that -- it works fine for me without any problems. And I like the moz-firefox integration in CentOS. In liferea, click to read a thread and it opens for reading in Firefox. Nice. But my favorite distro is Slackware 11.0 running KDE

Thanks.

--
Alan.

http://packages.debian.org/cgi-bin/s...le&release=all

Had meant to, but forgot to, include link to I found .deb liferea package.

--
Alan.

"use this src2pkg on a .deb to get a dependency list"

We've been doing this with source compiles for awhile, but only when a build fails. We search for an RPM .spec file or Debian control and show requires.
To see this use the -V option with src2pkg (or REPLAY_ERRORS=YES in script).

The new feature which *converts* .deb and .rpm binaries does something a
little different which is also available with source builds. When you convert the .deb we run ldd on the executables and show a list of the libraries required by the package. This is needed since you didn't comile them on your system and we don't know if if all deps are met, so we show you them. You can also do this when compiling sources (by passing SHOW_DEPS=YES)
Note that the former shows debian or rpm package names and the latter shows raw library names.

"build the pkg"
To convert a binary Debian .deb or .rpm archive just type the name as you find it. Examples:

src2pkg python-gdk-imlib-1.2_0.6.12-2_i386.deb

"build each of its dependency for Slackware 11.0."
We don't do this, since we don't yet even support URL location of sources. However we make it easy to chain-build and install packages once you have the sources available and know what order they need to be in. This will work for source compiles or binary package conversions.

Chain-Build HOWTO
Just create a project area with a subdirectory for each package and make each script as usual.
Make a list of the package subdirectories in the desired copile order.
Create a small script to cd into each directory and run the build script there:

That was a pretty easy package, actually. I downloaded the sources from the debian pool along with the diff file which shows that it needs GTK2, atk, pango, cairo -all in your standard Slackware. It also requires GConf-2 and either gtkhtml2 or firefox/mozilla. GConf-2 needs ORbit2 as well.
You can get the GConf-2 and ORbit-2 stuff from here if you need them:
http://distro.ibiblio.org/pub/linux/...E-COMPAT-2.10/

Once you have the above, you can compile liferea with just:
src2pkg liferea_0.9.1.tar.gz


You can get the sources or package I made here:
http://distro.ibiblio.org/pub/linux/...liferea-0.9.1/

I tried it on inkscape:

However the end of a normal ./configure gives:

So whilst I think src2pkg made a good try here in the face of adversity (I needed to reinstall libpng as somehow the .pc file had gone astray, I'm blaming slackpkg for that!) it could, it seems, have been more verbose with respect to the error - configure correctly identified the problem.

Fixing that libpng error and trying again ...

Also incidentally I'd be happier if this all ran as a user and just used the root password if installation was requested.

Running in the default QUIET mode turns off all the ouput from configure, make and make install. If you use the -V option, src2pkg will open a new xterm and rerun the failed command so you can see what the specific error was. You can also see the whole thing the first time around by using the -VV option to not suppress output.
It would take many.many thousands of lines of code to try and figure out what the errors are when something fails and do anything about it. My best idea(for down the road) is to parse out requires and congfigure/build commands from any existing .spec or control file and try those options when building has failed. Even this is just a stab in the dark, unless we used some form of real dependency checking and resolution. Note that I don't claim that src2pkg can or should do this -it's a very tall order indeed. Working out depends and chain-compile orders is nice work for an enthusiast. src2pkg makes the tedious rebuilds and fine tunign easier along the way.

I've considered several methods for building packages as non-root user. There are a couple of advantages and some disadvantages as well. Non-root builds are safer from a system standpoint, but some software doesn't work when compiled as a user and then installed as root.
You can easily do this though by using trackinstall. Just unpack, configure and compile your software as normal(manually, I mean). Then cd into the sources, su to root and make the package with 'trackinstall'.

Generally, compiling and trying to compile lots of unknown software on a production machine is not a good idea, unless you know how to fix things. I've tried to make src2pkg as dependable and trouble-free as possible when building as 'root' -note that SlackBuilds require you to be 'root' since makepkg itself requires it. One of the reasons we do the installation-tracking the way we do is to insure that everything on your system is exactly the way it was before you started -this happens even before package-making is finished.
I appreciate the feedback and suggestions and they are not lost on me. They do help shape the future of the program.