SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have just started using src2pkg and can I say: I am mighty impressed! I have created a package for the svn slrn which I have a couple of queries about. The (very minimally modified) script is:
Code:
#!/bin/bash
## src2pkg script for: slrn
## Auto-generated by src2pkg-1.7
## src2pkg Copyright 2005-2007 Gilbert Ashley <amigo@ibilio.org>
## Full package name: slrn-pre0.9.9-i486-69.tgz
SOURCE_NAME='slrn-pre0.9.9.tar.bz2'
NAME='slrn'
VERSION='pre0.9.9'
ARCH='i486'
BUILD='69'
PRE_FIX='/usr/local'
# Any extra options go here
# EXTRA_CONFIGS=''
STD_FLAGS='-O2 -march=i486 -mtune=i686'
if [ -e /usr/lib/gcc/i486-slackware-linux/4.1.2/include/slang.h ]; then
mv /usr/lib/gcc/i486-slackware-linux/4.1.2/include/slang.h /usr/lib/gcc/i486-slackware-linux/4.1.2/include/slang.h_bak
fi
# Get the functions and configs
. /usr/libexec/src2pkg/FUNCTIONS ;
# do_all_processes can substitute these 16 steps:
pre_process
find_source
make_dirs
unpack_source
fix_source_perms
configure_source
compile_source
fake_install
fix_pkg_perms
strip_bins
create_docs
compress_man_pages
make_description
make_doinst
make_package
post_process
# src2pkg - Copyright 2005-2007 Gilbert Ashley <amigo@ibiblio.org>
## See the documentation for more help and examples. Below are some of
# the most common Extras and Options for easy cut-and-paste use.
# EXTRA_CONFIGS='' PRE_FIX='' DOCLIST=''
# MAKE_COMMAND='' INSTALL_LINE=''
# SHELL_INSTALL='YES' CORRECT_PERMS='NO'
My questions are:
Is there any particular 'optimal' place for the conditional statement I have used? It must be before the compile process for compile to succeed but I have just dropped it in an empty space :-)
A little bit aside from src2pkg but do you feel that the gcc options:'-O2 -march=i486 -mtune=i686' make that much of a difference? I have always compiled 'by hand' without these options and only really became aware of them when I looked at Slackbuilds scripts and now src2pkg options. Sorry, this is a noob question :-)
Do you feel that there is a place in your scripts for initial commands to download from an svn repository, tar the results, and then run the script? Looks like it can be done with a little fiddling but I have a suspicion that this might be pushing the purpose of src2pkg a little further than its purpose?
Anyway thanks for the great program, it has made my entry into Slackware packages very straightforward! FWIW I have temporarily posted the results of the slrn script at:
1. Try to get rid of it. You should complain to the slrn guys to make it so you don't have to do that. Hacks are OK if you can't get upstream to change it (either because it's already released source, or really old and nobody does anything with it anymore, or whatever other reason), but for SVN builds it really needs to be dealt with properly.
2. -O2 is normal optimization that most non-debug builds do anyway. -march=i486 -mtune=i686 is to build it so that it can run on a i486 but can take advantage of i686 optimizations. If you don't put the -march option in, you lose the ability for the package to run on older hardware, and if you don't put in -mtune, you lose some performance for the common case.
3. I don't think it's build-in yet, but it's fairly easy to add as another SOURCE_URL protocol. The tricky part would be to not tar up the source only to extract it again, and to detect the right version identifier (e.g. "5049svn"). It's been on my personal TODO to contribute something that does this, but I've been busy with classwork and other projects. Now though, I'm waiting for src2pkg 2.0 that supports building and packaging as a normal user.
1. Try to get rid of it. You should complain to the slrn guys to make it so you don't have to do that. Hacks are OK if you can't get upstream to change it (either because it's already released source, or really old and nobody does anything with it anymore, or whatever other reason), but for SVN builds it really needs to be dealt with properly.
I believe that this is a Slackware 12 problem rather than an slrn problem. gcc fixincludes has generated an extra slang.h as /usr/lib/gcc/i486-slackware-linux/4.1.2/include/slang.h which contains the following lines:
This actually renders it difficult to compile slrn against the default 2.0.7. I have emailed both PV and JED with the details. But yes, I would be happier without this in place.
Quote:
Originally Posted by tuxdev
2. -O2 is normal optimization that most non-debug builds do anyway. -march=i486 -mtune=i686 is to build it so that it can run on a i486 but can take advantage of i686 optimizations. If you don't put the -march option in, you lose the ability for the package to run on older hardware, and if you don't put in -mtune, you lose some performance for the common case.
Thanks for explaining this, I obviously need to do more than a little background reading on this issue. FWIW I compiled both with and without these options and while I could not assess performance on multiple different machines I did notice the package with the optimisation was 30kbs lighter.
Quote:
Originally Posted by tuxdev
3. I don't think it's build-in yet, but it's fairly easy to add as another SOURCE_URL protocol. The tricky part would be to not tar up the source only to extract it again, and to detect the right version identifier (e.g. "5049svn"). It's been on my personal TODO to contribute something that does this, but I've been busy with classwork and other projects. Now though, I'm waiting for src2pkg 2.0 that supports building and packaging as a normal user.
It was only really speculation on my part and to tell the truth I am a little uncomfortable with too much automation :-) However I am picking up a book on shell scripting this Xmas so hopefully I can have a shot at it myself: "Classic Shell Scripting" by Robbins & Beebe.
You could put the commands you want just below what you have already added. You should probably add lines after post_process to restore the file to its' original name. Any place before pre_process would be fine.
However, It might be best to put the commands for downloading and creating a tarball into a separate script that would then call the src2pkg script or run it with command-line options. That would probably allow more leeway for doing whatever you want with the download routine.
I really recommend that you download and create your 'snapshot' separately. By the time you add all the sanity checks, etc it may be quite a few lines of code. If you use variables for determining and setting the version you can use the script with any version. src2pkg is designed to make it easy to be driven by another script and your method could be used as a template for doing this sort of thing by others. This would probably be more dependable than trying to incorporate the code into the src2pkg download code.
I'd be interested in whatever you come up with. src2pkg does contain a bit of code especially for working with CVS or SVN sources -thanks to suggestions from tuxdev. If you or he comes up with something that looks like it could be cleanly integrated into the main program, then I'll do that.
Thanks for that gnashley. I have adjusted the script as you suggested and it all runs well.
It is a little depressing putting this work into the svn slrn / Slackware package creation when you can imagine the diminishing numbers:
1. The number of people who use Linux
2. The number of these who use Slackware
3. The number of these who still use Usenet
4. The number of these who a dedicated newsreader
5. The number of those who put the effort into running slrn
6. The number of these who are interested in the subversion slrn
And there I am on number 7 : those who wish to neatly package up the svn slrn and publish a walkthrough. Hmmmm......
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.