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.
The following Build Options require an argument separated by the '=' sign.
Use single quotes '' around the arguments if they contain spaces.
-p (--pre_fix,--prefix) Set the package installation prefix. [-p=/usr/local]
Thanks for the great software gnashley. I was using checkinstall because I'm new and it was so highly recommended on this board, but then recently I learned it can cause problems. Src2pkg works great. I have to admit though I haven't learned any of its options. Seems to work fine just as it is. I like simple.
Okay, first of all: the -X option is used for running a script which you have already created using the -N option. Firts create the script with the -N option and any of the build options which you know you might need, if any. Then, once the script is created you can run it with simply 'src2pkg -X'. You can mix in other of the user options (with capital letters, but not -N or -A). Do not add build options with lowercase letters when using the -X option as they will be ignored and may confuse src2pkg.
For what you are doing you can generate a skeleton script with:
src2pkg -N avr-libc-1.4.7.tar.bz2
Then open the script with your favorite editor and comment the lines:
Then write something like this in:
cd $SRC_DIR ;
make DESTDIR=$PKG_DIR install
I think your problems with configure are probably due to using the mixed options as I explained. But if you still get errors when configuring, you may need to comment out that also and run it manually as above for make and make install.
(cd $SRC_DIR && ./configure ....options)
When cross compiling or using other really unusual commands for configure and make it is usually easiest to just comment out the lines and do the steps manually. This still lets you enjoy the benefits of automating all the other steps including temporary file and directory cleanup.
You can run the modified script then with:
src2pkg -X -C -VV (or with more options like -W and -I)
To digger95: glad you like it and that it makes it easy for you to use, even without options (so far).
To LocoMojo: I got your e-mail with the attached changes to the FUNCTIONS file. I haven't had a chance to try it out yet, though it seems that it will work fine without changes. I will consider including such a feature, but as you suggested it would be as an explicit option which could be passed from the command-line, or by inserting in a script or making it the default behaviour by putting it in the src2pkg.conf file. The part about entering a package description was one of the things that I disliked most about checkinstall. In the past removepkg would not work on packages that didn't have a correctly formed slack-desc file, and this meant that you had to put something for all 11 lines of the file during the checkinstall build process. So, I just had src2pkg create a valid file or insert the one you supply (after checking it for validity.) I really mean someday to add code which will parse description text from any description info that is found -like from a .dsc or .txt file used with Slackware, or from an rpm .spec file, debian 'control' file or .lsm file found inside the sources. Reading and formatting the text is not trivial, especially since I want to do it without awk or sed. I do have some scraps of code around for the job though. But I've been quite busy with other projects lately.
I don't even use src2pkg so much as I use trackinstall that comes bundled with it and I thank you so much for this very program gnashley. Is there any reason why I shouldn't skip on the whole src2pkg and just use trackinstall? If there's no reason, then it's the perfect checkinstall replacement because it does the exact same thing. In my experience trackinstall has worked wonderfully. I say ditch checkinstall and use trackinstall (unless gnashley says not to).
jowa45, this line
make DESTDIR=$PKG_DIR install
should install the program directly to the package tree without overwriting your already installed program. Then the rest of the package build proceeds normally. You have to get the content of the program into the PKG_DIR in order to get a package. The normal way that src2pkg does it (with the 'fake_install' function) is to use installwatch to track what happens when 'make install' is run -without using DESTDIR. Then it copies the files created into the PKG_DIR and creates the package from that.
Either way you must run some sort of 'make install' or you have no content in the package tree. It really is more dependable to not use DESTDIR and let src2pkg track the file and directory creation when directly running 'make install'.
Is your cross-compiler installed into it's own subdirectory or is it, as seems, installed into your regular path and uses binaries with the 'avr-' prefix? I think you'd get better results by compiling your cross compiler to reside in it's own directory (like /usr/avr-gvv or /opt/avr-gcc). Then create a wrapper for it that you put in your normal path. This avoids lots of problems.
You say that you have already compiled and installed your program manually. What commands did you use to configure, compile and install it?
Inuit-Uprising: there is no reason to not use trackinstall if it does what you want. The reason I recommend using src2pkg is that it encourages you to use a script -which means you have a record of any configuration options which you have used before compiling the software. If you are compiling using the simple './configure --prefix=/usr && make && make install' then there is no special information to save as this is the default that src2pkg uses. Using src2pkg from start to finish also makes it much faster and easier to repeat the build since it takes care of all the cleanup operations. There are cases where trackinstall may be preferable -like when a user insists on configuring and compiling while logged in a s a normal user. Then you can just su to root and run trackinstall to create the package. Also, trackinstall is better at creating packages from programs which install by running some sort of script like: 'sh install.sh'. In that case a simple 'srcpkg -S' suffices. If the script is name something besides 'install.sh', you just use the -i='' option to pass the command used to run the installation. This even works with installers that run interactively and ask you where to install stuff.
I rarely use trackinstall myself and sometimes worry that bugs or glitches might creep in from changes I make to the FUNCTIONS which affect both src2pkg and trackinstall. So, I'd appreciate it if you let me know quickly if you have trouble with using trackinstall.
Please note that tarckinstall can also create and use scripts -they are called *.TrackBuild scripts. These are useful if you need to add commands to 'massage' the package content in any way, like adding extra documents or whatever.
I will try to explain a little more fully. Yes I have a source code installation of the tool chain. It was installed on Slackware 11 just after that came and has been in daily use since with little problem. Then earlier this year I saw a post " The Magic Package Maker comes of Age " when src2pkg was introduced. After a lot of help I achieved packages for all members of the tool chain except the library files.
When I came to use these packages on other computers with first Slackware 11 and then 12 they work fine. I can install the tool chain even on minimal Slackware installations which have nothing from Slackware D or L by installing first the packages that I do have and then installing the library files from source. It works because the cross compiler installed from package is called which I imagine then looks for files only in the other installed members of the tool chain.
To install from source code
tar -xvzf avr-libc-1.4.7.tar.bz2
./configure --prefix=/usr/local/avr --build='./config.guess' --host=avr
With all installations I have put /usr/local/avr/bin in path even before beginning tool chain installation.
With the advent of src2pkg1.6 I have returned to the idea of making a package due to the success of the packages I did achieve. I would like firstly a script with the -N switch so before I get too confused lets just start again and get a script first and when I see what it looks like we can consider editing it.
Many programs don't do well with spaces in file or path names, so src2pkg is no exception there. I haven't had the problem myself, nor have I had reports of it before so I hadn't thought about it. I'll see what can be done about that.
src2pkg requires you to be root because it actually runs 'make install' during the process of package creation. While there are methods to build packages without being root, they are not foolproof. Being root insures that all permissions are correctly set when the package is made, so that the package can be installed and run by any user, the same as any official Slackware package. Note that you must also be root to build packages using SlackBuild scripts in order for perms and ownership to be correctly set.
I submitted my review of src2pkg 1.6 to Linux.com last night. I'll post here when it is published. :-D
Overall I was very impressed with your program and I'm glad I took the time to begin learning how to use it.
I've still got some questions, but I'm beginning to see how I might figure out the answers. For instance, looking at the SlackBuild from Slackbuilds.org for Open Office one sees the following comments indicating corrections to the package to optimize it for Slackware:
# Create symlinks in /usr/bin to actual binaries and edit the
# included wrapper scripts /usr/bin to correct the paths
# Correct symlinks in /usr/share/applications
# Correct icon paths and Exec commands in the desktop files
# See http://bugzilla.xfce.org/show_bug.cgi?id=2430 for why we want to
# change the Exec lines
# Add /usr/share/pixmaps directory and link icons to it
# Move docs to their correct locations
# Fix the permissions on a few icons that are executable
I'm not sure how to accomplish those tasks using src2pkg, but I suspect using a src2pkg script or a do_install.sh script running after the installation is the way to go.
I actually did not build OpenOffice 2.3 for my review. But I did build Emacs 22.1, Scribus, Opera, and I converted an RPM for a game called Orbit.
My one piece of constructive criticism is that the documentation, while well-written and informative, is spread out over too many files. I feel it would be helpful if they were consolidated into a single info or man file.