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.
Thanks for that Gnashley, I'm really not trying to be awkward, but I also tried firestarter (an iptables configurator (sic.))
It installs but on running gives:
A proper configuration for Firestarter was not found. If you are running Firestarter from the directory you built it in, run 'make install-data-local' to install a configuration, or simply 'make install' to install the whole program.
Firestarter will now close.
A normal ./configure && make followed by checkinstall as root installs with no problems.
So tuxdev with another challenge. smlnj has its' own one-command installer which downloads, compiles and locally installs selected targets.
Creating a snapshot of the archives would make things easier, but src2pkg still makes it pretty easy so you can configure your targets and keep up-to-date
when there are changes to the main sources.
There are probably several ways to do this with src2pkg or trackinstall, but I chose the most straightforward method of commenting out the unneded steps and inserting manual code to handle the install script and copying files to the PKG_DIR. Since this is a compiler collection it also is best installed in its' own subdir, so I put it in /opt/smlnj and put a wrapper in /usr/bin for setting up the path, etc.
This serves as a good example of how flexibly you can use the src2pkg functions, so I'll include the full script here. Bear in mind that the smlnj installer downloads the tarballs, so you must be connect to the interenet when you run this script.
## src2pkg script for: smlnj
## Auto-generated by src2pkg-1.1
## src2pkg Copyright 2006-2007 Gilbert Ashley <email@example.com>
# Any extra options go here
# Get the functions and configs
source /usr/libexec/src2pkg/FUNCTIONS ;
# do_all_processes can substitute these 16 steps:
# with src2pkg-1.1 you won't need this - it has AUTO_PATCH
cd $SRC_DIR && patch -p1 < $CWD/smlnj-targets.diff
cd $SRC_DIR ;
mkdir -p $PKG_DIR/$PRE_FIX
cp -a $SRC_DIR/bin $SRC_DIR/lib $PKG_DIR/$PRE_FIX
# install the wrapper
mkdir -p $PKG_DIR/usr/bin
cp -a $CWD/Resources/SMLNJ $PKG_DIR/usr/bin
chmod 755 $PKG_DIR/usr/bin/SMLNJ
mkdir -p $PKG_DIR/usr/doc/$NAME-$VERSION
cp -a $CWD/Resources/* PKG_DIR/usr/doc/$NAME-$VERSION
I hope you(tuxdev) will verify that the wrapper works correctly
so I can be sure to fix the package if needed.
Don't expect to see handling for this as an auto-feature in src2pkg... But it has some nice code for handling url's and stuff which may find it's way into 'find_source' later.
If I were playing with this software, I believe I'd set up the sources in a project dir (with all the tarballs present to avoid re-downloading), then use trackinstall to make the package. Or, I'd create a snapshot tarball of all the sources and work from that.
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.
After you install little handy tool called fakeroot it's no more true and root is required to do installpkg only. There remain some extremly rare cases when configuration/build requires uid 0 privileges (hal comes to mind) but it's rather improperly written autotools scripts/makefiles then reasoned need. Works well with Pat's SlackBuilds too
At first glance, it appears that the package is okay, but I'm not really capable of verifying it. It might be a more generally useful package to not patch the target. I have a certain amount of trust in defaults.
It seems I need tla to analyze fakeroot properly. I know that tla has an unusual build system, so it's a nice (minor) challenge for src2pkg too.
I agree it's probably better to exclude the patch so the default targets get built(though it sound like MLRISC may not be needed. Anyway, I just trimmed the list for testing purposes to avoid re-downloading and waiting. I'm probably gonna repack the whole default set into a workable single snapshot tarball.
Dunric, I'm getting around to looking at fakeroot or something similar. If you are having good results with it, then I'll definitely give it a whirl, rigourously, and see.
The original limitation was imposed because of using makepkg to create the final tgz. That code has been intzernalized now and the root restriction could be eliminated if file ownerships and perms can be handled with fakeroot or other.
Ok, I installed it, and it looks great, but I have a few questions.
I've never used build scripts before, so I'm a little confused. When I use the -A option it creates a script for me. How can I use this script in the future, when I'm building a new version of the same package, for instance? Is it for reference only or is there a way to tell src2pkg to use the same arguments?
Another thing, what's the correct way to make src2pkg always use some arguments (--arch, for example) every time? Should I put it in src2pkg.conf or create my own script with "src2pkg -a ...."?
-A should create a Foo.src2pkg file, and you can rerun the script by doing ./Foo.src2pkg if it's executable. You might have to edit a few things like the version number for a new version of the package.
Yes, the best place for options you always use is in src2pkg.conf. For --arch though, that's one option you should probably not use on a regular basis.