The 'Magic Package Maker' comes of age and changes its' name
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
You could put this in the script just before configure_source:
(adjust for your system.
When cross-building, usually you'll build your new library first and then compile and link binutils to the new libs. Then you compile the new comiler with the new binutils also linking against the new libs.
You'll need to modify the scripts some and perhaps use a 'group-build' to script the whole thing -that just usually just means a simple loop which builds each package and installs it as you go by setting the -I option.
I build a group of 20-30 GNOME packages using one or more scripts like this:
# for dir in `ls $CWD` ; do
TRANSIENT_OPTIONS="-V -I -W"
for dir in $BUILD_LIST ; do
if [[ -d $dir ]] ; then
# echo hello from $dir
echo "Running src2pkg $TRANSIENT_OPTIONS for $TARBALL"
src2pkg $TRANSIENT_OPTIONS $TARBALL
if [[ `ls $PKG_DEST_DIR/*.tgz |grep "i486"` != "" ]] ; then
echo "Installing package..."
echo "Where's the beef?"
This new version includes:
- a routine for automatically downloading an archive if not already on your system. Example:
- a routine for auto-applying patch and diff files
- support for s390 and x86_64 architecures
- added support for x86_64 to src2pkg build script
- better document search and allows packages with no docs
- updated code for compatibility with BASH-3.2
- support for updating and/or executing existing src2pkg or PkgBuild scripts -allows you to control src2pkg user options from command line while still using a script:
src2pkg -U -X oldstyle.PkgBuild
'src2pkg -X' will search the current directory and run the first
.src2pkg, .src2pkg.auto, .PkgBuild or .PkgBuild.auto script found.
This code is still rudimentary -it searches for patches or diffs in the CWD (current working directory) or in a subdirectory called patches and applies them in sort order.
They can be be either uncompressed .diff or .patch files or compressed patches with gzip or bzip2. Application order can be controlled by renaming files.
Patches are applied using the -p1 option which is the most common. Otherwise, you'll need to write code to apply patches.
You could pretty easily insert code into a .src2pkg script which would also download any need patches -I've been thinking about some solutions for handling multiple-source builds.
As far as my little project goes I can now install the toolchain on a minimal installation (only a, e & make from d)by installing the packages that I made for binutils and avr-gcc and then a source code installation of the avrlibc. Works as above because it calls avr-gcc not gcc. Then I can install the programmer package. Total installed size around 200K.
Will be pushing on with the script and packaging though but my current endeavor is to get Slackware 11 into some ancient laptops and then install the toolchain.
I was vaguely wondering how src2pkg compared with the alternatives which come in the Slackware distribution like makepkg and slacktrack.
makepkg is used to create packages from content you already created, usually by running a .SlackBuild script. slacktrack uses a spec file to replace the SlackBuild and also run makepkg to create the final package.
src2pkg can also use a spec file (.src2pkg or .PkgBuild) to create simple or complicated packages from a wide variety of content types, or it can do so from the command line.
What really sets src2pkg apart from other package creators is the way it automatically figures out (usually) what to do without much help. It also does some pretty thorough correction of common problems, both in the sources and package. And it will write its' own script for you, in case you need to make any changes not available as options.
You really can't get much easier than this: Say you know of a program you want and you have the URL to the source tarball. Just give that to src2pkg (while connected to internet) and it will do the whole bit, downloading the tarball, compiling and creating the package.
src2pkg works with all these build systems automatically:
- simple Makefile
- autoconf (.configure, make, make install) runs autogen.sh or repairs
faulty config files when necessary
- scons build system
- jam build system
- noarch or customized content creation are easy
- handles installations of sources or binaries which use a .run file or install.sh (like flash_player or Opera, etc) or other install script.
- converts binary .rpm or .deb packages to sane Slackware standards.
- converts other installable binary content to sane Slackware content.
It handles the following source archive suffixes:
.tgz, .tar.gz, .tbz, .tar.bz2, .rpm, .deb;
OK, admittedly I haven't re-read the latest posts in this thread, and I'm going to bed after I type this.
I just had to stop in and say THANK YOU to Gnashley for 'src2pkg' which I finally got around to trying out earlier today, and was impressed such that I spent much of the day building ALL of the non-Slackware packages I have here in my system. It works great
I did have to/want to tweak a few Makefiles here and there (for reason indicated below) but all in all, happiness reigned (rained? which is it supposed to be?) ahem-- 'RAINED' across the land!
So, two points/questions:
1 - can multiple 'make' statements be applied? Sometimes ONE -m='make' and ONE -i='install' were not enough.
2 - Sometime after downloading src2pkg the first time, I couldn't find it on my system, so I went looking for the website. The site, or the tool (I can't now remember which) were nowhere to be found. Incase there's a new release, I am interested, so just wanted to be sure the program is still available, and that I know where to go looking.
EDIT - Upon post/refresh I see website and new-release info above, in this very page! I'll check into it tomorrow.
PS - Know what's funny?? When I first started with it today, I rebuilt my first package over and over about a dozen times before I realized that the hell was wrong -- that the SLACK-DESC file did not belong INSIDE the archive, as I had been putting it! Silly me...
Last edited by GrapefruiTgirl; 05-29-2007 at 11:51 PM.
Thanks -happiness reigns(rules).
Yes, you can use multiple Makefile rules in one statement:
-m='make depend all'
-i='make install install_data'
Once you see how it works and have some confidence with it, it's pretty easy to produce packages quickly, when there aren't too many special steps required. I've produced as many as 30 in one day -still taking my time to check them well.
I'm going to be uploading a new release in the next few days with improvements in the control of the auto-patching feature. Also, you will now be able to have a script which will download multiple source files and build them. The main thing I'm working on is getting some new documentation in the package. The new version will also be using the latest version of the installwatch libs.