After two months of intensive development, src2pkg-2.7 is now released. The last release was only in December, but I started coding wildy the very next day...

Most of the changes are related to package-splitting and the new kiss *.tpkg format, but there were a few small bug-fixes which affected all package formats.

From the CHANGES file:
== Version 2.7 == 15 Feb 2012

This version fixes a couple of minor bugs and adds many
enhancements for the KISS-linux 'tpkg' package format.
Some of that code was separated from routines for
Slackware packages, so the Slackware routines are cleaner.

Notes on upgrading:
As user root, run 'src2pkg --setup' after upgrading
from any earlier version.

Some new configuration options have been implemented,
so check the new version against any existing one.

The full ChangeLog is here:
http://distro.ibiblio.org/amigolinux/download/src2pkg/CHANGES

The installable pet package for Puppy is here:
http://distro.ibiblio.org/amigolinux/download/src2pkg/src2pkg-2.7/src2pkg-2.7-noarch-2.pet

Thanks to Jemimah for reporting a problem with invalid links when splitting packages.

Edit: I forgot to mention that the pet package now installs a pre-configured conf file which should allow instant usage on Puppy, with all the configurations options set to produce pet packages, without the user needing to edit the conf file.

If installing src2pkg for the first time, you will automatically get this conf file. But, if you have installed src2pkg before and have an existing /etc/src2pkg/src2pkg.conf file, you should rename it so that the new gets installed *and activated*. Then, compare your old file with the new one to see if you have any extra options which are not already set up in the new one.

Edited to update link to fixed package -there was a problem with syntax when using bash4.Last edited by amigo on Thu 16 Feb 2012, 05:26; edited 2 times in total

src2pkg is an 8-year-old project now, so it has become quite mature at what it does:

Create a package from source code or other content with a single command -sometimes without any 'recipe' or extra arguments. It can download a given source URL, configure the sources, compile them, create the package and install it with a single command. It is still the only packaging system out there which can *sometimes* create a package without any expertise on the part of the user vis-a-vis compiling and/or creating sane packages, and often do so without any sort of 'recipe', 'spell', 'port', SlackBuild script. or whatever the distro uses to create packages.

src2pkg has supported the pet format for several years now. src2pkg focuses on creating really sane, uniform packages in a repeatable fashion. The recipes (*.srcpkg scripts), when used, are very brief, flexible and easy to edit so that it is possible to create even the most complex packges from them -no matter what. The *.src2pkg scripts are architecture-agnostic, so the same script can be used no matter what architecture they are used on.

src2pkg is script-based, but also depends on several binary programs and libraries. The sources for these are all included in the src2pkg package, and will be compiled, packaged and installed *on your system* after installation of the src2pkg package. This is done so that every user gets the bins and libs compiled for their exact system -no chance for incompatibilities.

The really shortest tutorial:
1. Install the pet package linked to in the original post.
2. Open a terminal (xterm or rxvt) anywhere and type the command:
src2pkg --setup
That will configure and compile the included sources, and create and install a pet package called src2pkg-helpers-VERSION-ARCH-BUILD.pet
3. Build the example package like this:
src2pkg http://distro.ibiblio.org/amigolinux/examples/di-3.11/di-3.11.tar.bz2
or:
src2pkg http://distro.ibiblio.org/amigolinux/examples/di-3.11/di.src2pkg.auto

As far as I know, Jemimah uses src2pkg to create some of her pets for Saluki. big_bass uses src2pkg to create *.txz packages for his Slaxer derivative. There are others here who are using src2pkg to build pets with.

src2pkg knows how to handle sources which use a plethora of configuration methods, including, autoconf, cmake, imake, jam and many others -perl, python and tcl sources included. src2pkg has five distinct methods for creating initial package content(normally the 'make install' command. The 5 methods allow for safe content creation without over-writing exisiting files -even when DESTDIR is not supported. One of the methods will always work. src2pkg performs many hundreds of sanity checks on the package content, correcting common errors in a flexible, configurable manner. src2pkg can automatically split packages into their run-time, development, documents and language files components.

src2pkg is meant for use by both rank beginners and packaging profis. src2pkg forms the basis for my KISS Linux distro, where it used to build every package on the system -above 1,000 at this time(from around 400 sources). src2pkg also includes a drop-in replacement for installwatch/checkinstall (libsentry/sentry) which is more robust and accurate than the originals. src2pkg includes ample documentation and examples. The script code used by src2pkg is over 10,000 lines and has been actively developed since 2004, tested and heartily approved of by many skeptical animals -er Slackers I mean.

Hope that gives you a hint about -searching the forum will show src2pkg mentioned and announced here many times.

Hi Amigo,
Does the devx need to installed to use src2pkg-2.7
just tried to run on puppy exprimo 5.x.13 without devx.

# src2pkg --setup
Notice - Creating src2pkg-helpers:
src2pkg uses a shared library and a few programs
when creating packages. For best compatibility,
these binaries will be compiled on your system.
They are then installed in a private directory.
When done, src2pkg is ready for use.

Found the problem. There were several reports also from folks on the Slackware forum also.

The qick fix is to simply edit /usr/libexec/src2pkg/FUNCTIONS
at line 135 from:
case $LINE in *' ') LINE=$(echo ${LINE:0:$((${#LINE}-1))) ;; esac
to:
case $LINE in *' ') LINE=$(echo ${LINE:0:$((${#LINE}-1))}) ;; esac
Notice the extra curly bracket near the end of the line.

When I first saw the reports I had a dread. Finding these errors can be very hard among thousands of lines of code. And, as you can see from this example, bash doesn't report the line number correctly. But it turned out to be easy to find.

I run bash3 here and was unable to reproduce the problem here at first. Both Slackware and some recent Puppies use bash4, so I figured it might be a bash4 problem. Using bash4 here I had the error too.

Fixing and upgrading for upload after a short while, so you can re-install. Or just use the quick-fix above.

Okay, this has been fixed and the original post has been edited to point to the new link.

Now, let me try to answer a couple of the questions:
majorfoo, "Notice - Skipping creation of unionfs-fuse -you don't have fuse installed." This is not a critical error. One of the five ways that src2pkg uses to isolate the files when something like 'make install' is run, is to use a temporary union mount using the real union file system *or* by using unionfs-fuse. In order to compile unionfs-fuse you need libfuse and the headers from libfuse, which is not present AFIK in your devx.sfs. It just means you lose one of 5 available methods which is not often used, nor required.

Jemimah, "script should display the messages using xdialog or gxmessage". Hmm, I'll work on a dedicated pinstall.sh script which does this, unless you wanna look at modifying the doinst.sh which gets converted to a pinstall.sh when I create the packages.

"QUERY_FOR_EXTRA_CONFIGS=YES" You won't want this if your start using *.src2pkg scripts to record your builds. If you are really needing to manually input certain configure options, that is exactly when you should be using build scripts you you don't forget what options were needed, and to save the pause during building. But you could simply do this:
src2pkg -Q -A ....
and have src2pkg automatically create the build script for you on successful completion of the package -it will write those options into the script for you, of course. At any rate, I'd suggest you use the command-line '-Q' option instead of making it the default so you can conveniently not use the option. Have a look at using the -ACF or -ACN
options as an alternative for commonly-used configure options.
You can also create a script before hand like this:
src2pkg -N -e='your configure options here' name-of-tarball
Then you only need to do this to execute that script:
src2pkg -X
and it's available for easy editing to customize anything you like.

"--splitpkg flag should be documented" It is. You have to look at the extended help:
src2pkg -hh (or src2pkg --more-help)
But it doesn't doesn't tell you much about the inner workings which you maybe are interested in. I use this for kiss:
src2pkg --splitpkg=devel,docs,nls
(there is also an option for 'solibs' which not often needed)
I first implemented doc-splitting as an all-or-nothing option, but that caused lots of tiny little docs packages to be created -sometimes with just one file in them. So, I implemented DOC_SPLIT_SIZE to let you control the cutoff-point. If the size of all the documents in the package is less than this minimum, the docs will not be split. This new option is at the very bottom of the new src2pkg.conf file. If you have upgraded or simply overinstalled this new version, then the new conf file will be at: /etc/src2pkg/src2pkg.conf.new
The pinstall.sh script uses a 'config ()' function which avoids the new package ober-writing your possibly-customized exisiting conf file. So you'll need to either copy the config option from the src2pkg.conf.new file, or backup and replace your old conf file with the new one. This 'config()' routine is commonly-used to avoid over-writing existing files and is generated automatically by src2pkg whenever it finds *.new files in the package. If you want to follow good-practice here when creating packages, then put a line in the *.src2pkg script for the package, which changes the name just after 'fake_install':
fake_install
mv $PKG_DIR/etc/my.conf $PKG_DIR/etc/my.conf.new
src2pkg will take care of the rest for you of writing the pinstall.sh

"Static libs and .la files in the plugins directory" Hmm, I'm still working to find ways to improve the algorithm used for this, so I'm very glad for another example package which poses this challenge and helps improve the heuristics. First, real plugins should not be part of a devel package. and plugins *can* be static archives, as far as I can tell. And *.la files are always required by plugins even when they are shared objects. Can you confirm that the static objects really aren't needed by the other plugins and are not plugins themselves? (by temporarily removing them and checking functionality). By default, src2pkg copies *.la files into the dev package tree instead of moving them, because there are some corner cases where the *.la files are need to properly link shared libs. There is a lot of debate about 'allowing' other progs/libs to depend on *.la files- debian goes to great lengths to avoid this -implies removing all *.la files. You can do this with src2pkg, but I can't help you with any compiling-linking problems which come up...
You can do that by putting this in your conf file:
REMOVE_LIBTOOL_FILES="YES"

The code which tries to make sense of *.la and *.a files is located in 09-fix_pkg_perms starting at line 96, where lists of certain file-types are being created. The lists are then used later when segregating package content in 14-last_minute_details starting at line 544. On the one hand, if the static files are not plugins, nor used by the other plugins, then should never have been installed there -a bug in the source Makefiles, which could be fixed with a tiny patch to the Makefile.am/Makefile.in files in that source subdir. However, this new src2pkg version offers and arbitrary method for fixing this -you can supply a list of wanted files for use when creating 'devel' or 'solibs' packages, instead of relying on the algorithm. So, a file named rawstudio-devel.files in the CWD would take care of that for you. Also, if using a *.src2pkg script (hint, hint), you could remove the offending static files from the main package content before package-splitting occurs. Just after fake_install:
rm -f $PKG_DIR/usr/share/rawstudio/plugins/*.a

That really is an interesting example which I will try out -I see *.la files there with no corresponding *.a or *.so files, so it really does get thick...

"What does the '-1' mean?" That number is the BUILD number which is very important for packages. When you rebuild a package which has changes apart from the VERSION of the sources, this number should be incremented so that the rebuilt package is clearly distinguished from the original build -both visually and for being able to sanely upgrade a package. pets do not require it, but apparently the package manager can work work with them -they are used by slack packages and every ohter form of packaging except slitaz *.taz packages. What should trigger bumping this number? Re-compiling using different configuration options, or edits you have made to files included in the package -any minor changes at all. When you upgrade to a newer source version, then you use '1' again. You can set the BUILD from the command-line using the '-b=?' option, or preferably, you bump it in that nice *.src2pkg script you are using, accompanied by a comment to yourself about why you rebuilt it, what was changed.
Remember that, once you have a script, you only need to 'src2pkg -X' to run it as many times as needed till you have fixed everything needed to create the perfect package. Use the '--resume=fake_install' command-line option to avoid having to re-compile everything for long builds.

To all, of course src2pkg requires the devx file since what it normally does is to compile sources...

i made the directory into a .tar.gz - then i run src2pkg on it, it get part way then fails on FAILED!! No INSTALL_LINE given. i know i should read the documentation but any quick tips would be appreciated.

This litle bit of output:
"Skipping compile_source -
FAILED!! No INSTALL_LINE given."
points there being no Makefile. In this case it means that configuration has failed. If you wonder why it didn't flatly fail when trying to configure, it is because the cmake routines are a little crude compared to autocnf configuration routines.

"So far i have built yad and this worked" -glad to hear that as it encourages you to keep on. It really is surprising how many sources are just that easy.

"src2pkg /usr/src/src2pkg/builds/tint2.tar.gz" That's really not a very useful version number. It would be good to re-name the original downloaded directory to something like:
tint-2-svn-20120216 and re-create your tarball. Then to make things really pretty (and useful), use:
src2pkg -n=tint2 -v=20120216 tint-2-svn-20120216.tar.gz
(if src2pkg fails to guess such values for such a name. Or you could ensure that by naming the archive tint2-20120216) Anyway, this illustrates how you can override the name or version number when needed. If you are using a *.src2pkg script then these options become:
ALT_NAME=tint2
ALT_VERSION=20120216

"noob like me anyway" src2pkg will make you shine and produce really professional-quality packages!

"QUERY_FOR_EXTRA_CONFIGS=YES" You won't want this if your start using *.src2pkg scripts to record your builds. If you are really needing to manually input certain configure options, that is exactly when you should be using build scripts you you don't forget what options were needed, and to save the pause during building. But you could simply do this:

The primary use case for src2pkg on puppy is to enable non-experts to build things. More advanced users can easily turn this off, but newbies aren't going to read the documentation or understand what a recipe is or how to make one.

amigo wrote:

"Static libs and .la files in the plugins directory" Hmm, I'm still working to find ways to improve the algorithm used for this, so I'm very glad for another example package which poses this challenge and helps improve the heuristics. First, real plugins should not be part of a devel package. and plugins *can* be static archives, as far as I can tell. And *.la files are always required by plugins even when they are shared objects. Can you confirm that the static objects really aren't needed by the other plugins and are not plugins themselves? (by temporarily removing them and checking functionality). By default, src2pkg copies *.la files into the dev package tree instead of moving them, because there are some corner cases where the *.la files are need to properly link shared libs

Barry's packaging tool always moves all .a and .la files the the DEV package. So far, I have never seen a case where this has caused an issue. (Sometimes, however, it moves .so files that it should not, which does cause a problem).

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum