src2pkg-2.7 - create packages from any source code

Miscellaneous tools
Message
Author
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

src2pkg-2.7 - create packages from any source code

#1 Post by amigo »

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/do ... kg/CHANGES

The installable pet package for Puppy is here:
http://distro.ibiblio.org/amigolinux/do ... arch-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, 09:26, edited 2 times in total.

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#2 Post by Flash »

Would you mind telling us what src2pkg is supposed to do?

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#3 Post by amigo »

Flash, src2pkg creates packages from source code or other content. In can create packages for Slackware, KISS Linux, *.rpm packages, *.deb packages, *.taz packages for slitaz and *.pet packages for Puppy (new-style or old-style).

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/ex ... 11.tar.bz2
or:
src2pkg http://distro.ibiblio.org/amigolinux/ex ... c2pkg.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.

majorfoo
Posts: 448
Joined: Mon 07 Mar 2011, 22:27
Location: Wish I knew

#4 Post by majorfoo »

amigo wrote:Flash, src2pkg creates packages from source code or other content. In can create packages for Slackware, KISS Linux, *.rpm packages, *.deb packages, *.taz packages for slitaz and *.pet packages for Puppy (new-style or old-style).
Will this application handle source files like xxxxxx.tar.gz
In other words, with a tar.gz extension

I would like to create pet packages from source files with this extension without going through the make, make install, etc routine.

thanks
majorfoo

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#5 Post by amigo »

That's exactly what it does. Follow steps 1, 2 and 3 in the post above and let me know if you have any problems.

stu90

#6 Post by stu90 »

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.

TEMP_DIR=/usr/src/src2pkg/builds/src2pkg-helpers
Starting build in 5 seconds
/usr/libexec/src2pkg/FUNCTIONS: line 275: syntax error near unexpected token `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: `}'
/usr/src/src2pkg/src2pkg-helpers/src2pkg.setup: line 601: get_flags: command not found
Unpacking sources - OK
Creating libsentry - Ooops! Can't live without it...

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#7 Post by jemimah »

Here is my preliminary feedback after a quick test.

The installer script should display the messages using xdialog or gxmessage or something. No one will see them if they only echo.

I think the following settings should be default:

Code: Select all

QUIET="NO"
QUERY_FOR_EXTRA_CONFIGS=YES
Otherwise it's impossible to diagnose and fix build problems.

--splitpkg flag should be documented in src2pkg --help. Right now the only place I can find it mentioned at all is the changelog. I think splitpkg should be the default on puppy.

Package names end up like pkgname-2.0-i486-1. What does the '-1' mean? Can it be turned off?

Docs remained in the bin package, even though I requested them split.

Static libs and .la files in the plugins directory didn't get split into the DEV package

Code: Select all

rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/demosaic.la
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/dcp.a
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/fuji_rotate.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/meta_raf.la
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/rotate.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/colorspace_srgb.la
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/meta_tiff.la
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/input_file.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/load_gdk.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/meta_ciff.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/crop.a
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/load_rawspeed.a

Other than that is is working great! Thanks!

majorfoo
Posts: 448
Joined: Mon 07 Mar 2011, 22:27
Location: Wish I knew

#8 Post by majorfoo »

amigo wrote:That's exactly what it does. Follow steps 1, 2 and 3 in the post above and let me know if you have any problems.
Installed src2pkg in copy of lucid 528 which also has devx files installed.

received following:

Code: Select all

# src2pkg --setup
  Notice - Updating src2pkg-helpers:
  Your installed version of src2pkg-helpers needs to
  be updated. src2pkg will now compile, package
  and install the new version of src2pkg-helpers.

  TEMP_DIR=/usr/src/src2pkg/builds/src2pkg-helpers
  Starting build in 5 seconds
/usr/libexec/src2pkg/FUNCTIONS: line 275: syntax error near unexpected token `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: `}'
/usr/src/src2pkg/src2pkg-helpers/src2pkg.setup: line 601: get_flags: command not found
Unpacking sources - OK
Creating libsentry - OK
Creating tar-1.13 - OK
Creating coreutils - OK
Notice - Skipping creation of unionfs-fuse -you don't have fuse installed.
Creating pet package - Done 
Finished pet package is:
/usr/src/src2pkg/src2pkg-helpers/src2pkg-helpers-1.5-i486-1.pet
Installing pet package - Done src2pkg is now ready to use.
/root
appears devx files must be installed to use this app..

what about the errors on line 275 and 601.
also the skipping of unionfs-fuse

how do I correct these

majorfoo

stu90

#9 Post by stu90 »

yes devx seems to be needed - i have loaded Exprimo puppy devx and get the same message as Majorfoo.
src2pkg-helpers .pet was created then installed - Attempting to build example package returns:

# src2pkg http://distro.ibiblio.org/amigolinux/ex ... 11.tar.bz2
/usr/libexec/src2pkg/FUNCTIONS: line 275: syntax error near unexpected token `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: syntax error near unexpected token `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: `}'
/usr/bin/src2pkg: line 471: do_all_processes: command not found


cheers.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#10 Post by amigo »

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.

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#11 Post by pemasu »

Dpup Exprimo has bash 4.1 or 4.2 depending on version.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#12 Post by amigo »

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...

Did I get all the questions for now?

stu90

#13 Post by stu90 »

Hi Amigo,
I went a head an installed the updated version - it runs through the setup now with out any errors.

So far i have built yad and this worked :D

Now onto something more complicated ( for a noob like me anyway ) i wish to build the latest version of tint2 panel.

running command to download tint2 source: svn checkout http://tint2.googlecode.com/svn/trunk/ tint2-read-only

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.

Full terminal output:
# src2pkg /usr/src/src2pkg/builds/tint2.tar.gz
Found source archive: tint2.tar.gz
Creating working directories:
PKG_DIR=/usr/src/src2pkg/builds/tint-2-i486-1
SRC_DIR=/usr/src/src2pkg/builds/tint-2-src-1
Unpacking source archive - Done
Correcting source permissions - Done
Checking for patches - None found
Found 'cmake' configuration - Configuring using:
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DLIB_SUFFIX= -DCMAKE_BUILD_TYPE=Release -DLOCALSTATE_INSTALL_DIR=/usr/var -DSYSCONF_INSTALL_DIR=/usr/etc
Skipping compile_source -
FAILED!! No INSTALL_LINE given.


cheers.

UPDATE:
ok i run through again this time with the option -VV i see there was a missing dependency - once installed and run again build completed and make a .pet - nice! :)

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#14 Post by amigo »

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!

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#15 Post by jemimah »

amigo wrote: "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).

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#16 Post by amigo »

"enable non-experts" -first you can always install a conf file with whatever options you like for your users. I think non-experts are gonna be just as intimidated by being prompted *every* time to input something, when many times nothing is needed at all. When something *is* needed, the only way they are gonna know what to input is by asking for advice. In that case, it's just as easy to tell them how to use -e='--option1=1 --option2=2'
You can improve the chances of getting closer to perfect by using '-ACN'. What that does is look for a configurable list of options which are used nearly everywhere -like --mandir, --infodir and others. You can configure the list in the conf file -look for 'AUTO_CONFIG_OPTIONS' in the conf file and note that the list uses the option names without the '--' pre-prended -space-separated list of anything you like. The most useful ones are: mandir infodir sysconfdir localstatedir

Actually, I think "primary use case for src2pkg on puppy" should be for use by developers and contributors who want to create things that just work. Once a recipe is created, it can be used on any version or architecture so you avoid the mess of having to always painfully produce binary-packages which work on each version. I know you don't want to need recipes, but there is not a single 'real' distro which can do without them in some form or other. Even LFS uses script fragments recorded in a 'book' to produce the end result.
If normal non-hacking users are able to create even one workable package using src2pkg, then it has been a great help to them. at the very least it avoids creating any extremely damaging packages or damaging builds -even if they don't get a perfect package.

"all .a and .la files the the DEV package" This might actually explain some of the subtle breakages which are numerous. I'll grant you that the *.la files are almost never needed -but there are a few outstanding cases wher it is not true unless special care is taken further both up and down the dependency chain -libpng, libmng and libjpeg being the worst offenders. As I said, there may be packages which use static-file plugins and most packages with plugins do need the *.la files for *.so plugins since some are loaded by using ltdl from libtool. The next time I start a complete-system upgrade, I might try removing all *.la files the whole way through and see how far I get. In the meantime, I'll look at showing you how to get them all removed from the binary, but not the devel package. In the end, they are tiny compared to the real libs so they don't cost much. Remember, I have to offer defaults which work more times than they fail. Exceptions are a great case for a script.

Please continue the feedback of every sort.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#17 Post by amigo »

Okay Jemimah, here's your fix:

plugins-and-la-files-fix.diff:

Code: Select all

--- ./14A-last_minute_details.00	2012-02-16 21:52:23.000000000 +0000
+++ ./14A-last_minute_details	2012-02-16 21:52:41.000000000 +0000
@@ -662,7 +662,11 @@
 							THIS_DIR="$(dirname $FILE)"
 							mkdir -p "$PKG_BUILDS_DIR"/$DEVEL_PKG_NAME/$THIS_DIR
 							# copy, not move the *.la files, as they may be needed in the main package
-							cp -a "$PKG_DIR"/$FILE "$PKG_BUILDS_DIR"/$DEVEL_PKG_NAME/$THIS_DIR
+							if [[ $MOVE_LIBTOOL_FILES = "YES" ]] ; then
+								mv "$PKG_DIR"/$FILE "$PKG_BUILDS_DIR"/$DEVEL_PKG_NAME/$THIS_DIR
+							else
+								cp -a "$PKG_DIR"/$FILE "$PKG_BUILDS_DIR"/$DEVEL_PKG_NAME/$THIS_DIR
+							fi
 						done < "$SRC_DIR"/$NAME-libtool-files
 					fi
 					if [[ -s "$SRC_DIR"/$NAME-static-libs ]] ; then
--- ./09-fix_pkg_perms.00	2012-02-16 21:53:00.000000000 +0000
+++ ./09-fix_pkg_perms	2012-02-16 21:53:15.000000000 +0000
@@ -98,7 +98,7 @@
 	# this also lets us avoid using file so  much
 	find * -type f |while read FILE ; do
 	  case "$FILE" in
-		*/plugins/*|*/plugin/*) true ;; # no dependable way to check for any other plugins
+		# */plugins/*|*/plugin/*) true ;; # no dependable way to check for any other plugins
 		*.la) echo "$FILE" >> $SRC_DIR/$NAME-libtool-files ;;
 		# *.h|*.hh|*.inc) echo "$FILE" >> "$SRC_DIR"/$NAME-header-files ;;
 		# some packages like 'kbd' include *.inc files which are not header files
You'll need to copy that to /usr/libexec/src2pkg, cd in there and run:
patch -p1 < plugins-and-la-files-fix.diff
(or apply the changes manually).
Then, you also need to add this to the bottom of your conf file:

Code: Select all

# MOVE_LIBTOOL_FILES
# If you want to preserve libtool *.la files, but not have copies
# left in a split binary package, then uncomment this
[[ $MOVE_LIBTOOL_FILES ]] || MOVE_LIBTOOL_FILES="YES"
Pretty simple fix, but may need more complex handling if it causes any problems. From the ChangeLog:
Version-2.8 16 February 2012
- (14-last_minute_details) In segregate_sub_pkg_links, Fix an incorrect
path when checking validity of links before moving/copying link to devel package.
- (09-fix_pkg_perms) Stop ignoring files under plugin/plugins directories. libtool
files there were not being listed, so they were not getting chmod 644'ed correctly.
Plus, any static libs there were also being skipped when later splitting packages.
- (14-last_minute_details) Add an option to allow *moving* libtool *.la files into
the devel package instead of leaving copies of them in the main package. This change
and the above one, come from a discussion with Jemimah about plugins and the
possible necessity of *.la files in run-time packages. I'm still not convinced that
*.la files are never needed for loading *.so plugins -or even for some regular
*.so libraries. This option allows *all* *.la files to be moved out of the main package,
so should tell us, with time, whether there really are cases where the *.la files
should sometimes accompany *.so objects. If so, then we need a still-more
complex routine based on real-life cases to figure that out.
I'm posting the quick-fix for you here because src2pkg-2.8 will probably not be out for quite awhile -I only rush out a re-release for bonafide urgent bugs. Most of my users will never see these problems because they don't use package-splitting, so I am glad that we talked about it and, hopefully, found a solution for the problem.

majorfoo
Posts: 448
Joined: Mon 07 Mar 2011, 22:27
Location: Wish I knew

#18 Post by majorfoo »

Made changes to line 135 and tried again.
Compiled Xscreensaver-515.tar.gz. Installed the pet and most of the screensavers (approx 185 out of 200) work .

Tried again using abiword-2.9.2.tar.gz and received the following errors.

I am quite new at this and need to understand what I need to get a completed product
Attachments
src2pkg errors.png
(177.64 KiB) Downloaded 938 times

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#19 Post by amigo »

I can't see enough of the error utput there to be able to tell what happened. Re-run the same command but add '-VV' to the options. Then you should be able to scroll back up to see more error output. This happened not because of some fault of src2pkg, but because something essential (to abiword) is not installed on your system. You may need to look at the log file mentioned in the output -it will be in the toplevel of where the sources have been un-package and are being configured. Sometimes this type of error can be overcome by adding configure arguments which disable the need for the thing it is not finding.

If I get time later, I'll try compiling abiword here so I can more easily help you. If/when I succeed, then I'll pass the 'recipe' to you, if one is needed.

2byte
Posts: 353
Joined: Mon 09 Oct 2006, 18:10

#20 Post by 2byte »

amigo

I just used src2pkg to package and install the xz utilities. For a test, I did a plain configure (no args) /make/install and tried to use it. That was a big fail as some of the libraries were not in the right place. Then I did a clean build with a backup pupsave using src2pkg and installed the pet. Everything works perfectly. It was very impressive when the pet install created all of the needed symlinks without any input from me. I was also pleased to find copies of the pinstall.sh and xz.desc in the /usr/doc dir after installation. Nice touch.

One thing that would be good for us would be a means to specify a short text for the package description at build time. My package has 'No summary text for xz’ in the pet.specs. I looked for a way to do this and also looked in the generated xz.src2pkg.auto file but couldn’t find anything.

EDIT: Found it. /etc/src2pkg/src2pkg.conf, QUERY_FOR_PKG_DESC=YES

EDIT2: No, that only shows up in the *.desc file, not in pet.specs.


Post Reply