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.
I'm interested in --arch because I'm getting a machine with a 64bit processor, so I'll probably want to use it most of the time. The same goes for the lib dirs, etc., I believe it was already discussed in another post.
Hello everybody! Sorry, I have just returned from a week in hospital having had a replacement lumbar disk installed along with a few screws and stuff.
I'll have to check on what's happening with my domain -I have a few hundred e-mails to go through. I suspect that my registration fee has expired while I was out -I had been wondering to myself about it lately as it seemed about time for it to run out this year.
Don't worry about the site though, I'll get it back up pretty soon -I had been needing to refresh the whole content anyway since awhile ago and hadn't done so because I don't have flat-rate.
Thanks to tuxdev for so kindly attending to the questions meanwhile.
hoofer, have you tried any ia64 packages yet? I've not tried other arch's except for powerppc, so I may need to add a couple of lines to cover that better if it doesn't already work. Anytime you use an option more often than not, it's appropriate to put it in your scr2pkg.conf file. Options that go in an individual src2pkg script are for variances from package to package.
Once you have a src2pkg script you can run it with:
'sh pkgname.src2pkg' or as mentioned make it executable and run directly. I changed to creating them as non-executable to make editing easier and to prevent accidently running them if you happen to click on it.
Welcome back! Sounds both painful and nasty and I hope you're getting over it ... hope they've given you some awesome pillz to take the edge off
Anyway, a few weeks back i decided it was time to scrap my hacked upgrade of slamd64 (it started around coaster 4, and eventually ended up somewhere near 10, but was by no means clean!) and do a fresh reinstall of 11. I've learned some tricks in the past couple of years of using both slack and slamd64, so this was a good time to put some of those to use ... with this in mind I knew it was time to ditch make install and checkinstall and fully embrace the uber that is src2pkg (Hua!).
So, i did the reinstall and spent the next couple of days recompiling packages, 23 to be exact.
I've omitted the default options, you can get a hold of those anyway from the original file. Clearly, since I'm building for slamd64 most of the time I want to use those options. As advised by your good self, these options can still be set from command line or overridden as necessary.
I had some problems, however ...
Primarily the binary packages were problematic. I failed to generate a working script for VNC or rar or even nedit. I just couldn't find the right combination of lines to get sorted out.
I've actually gotten side tracked with the point of this post and can't remember what i was trying to say, I think it's something about x86_64 working fine in my experience, and maybe that i have problems with binary packages ... eh ... i can give you more details for whatever you need, my brain has just switched off!
"the uber that is src2pkg" -that's great! I quite immodestly agree. You making 23 packages in a couple of days proves the point -Ive managed to churn out 50-60 in a single day when they weren't problematic at all, so keep practising, haha.
You say the binary packages are problematic. Do you mean that the binaries won't run? When you use the -a option the ARCH in the package names get set without any problems. However, I suspect that the proper CFLAGS aren't getting passed to configure and make so the bins produced are probably 32bit (arches other than x86 get optimization set to '0' and no mcpu or mtune flags are passed. This will be pretty easy to fix I think. I could have done these steps the same way most other SlackBuild-based system are doing it without much trouble. But I wanted to do it a little differently so I only included code that I could personally test.
It'll still be a few days before I can sit at the box long enough and clear-minded enough(killer pills confirmation) to address this code properly. When I do I hope you'll be kind enough to test it out for me before including it in the next release.
I've never tried to compile VNC so I have no idea what the problem is there. What commands do you use to compile and install manually? Usually just substituting the 2-3 'offending' src2pkg functions with manual code in the script will fix it. I'll post here my nedit.src2pkg script here which serves as a typical example:
Note that this script was written for PkgBuild-0.3 and should work fine as shown. However, later versions take care of several things automatically which are done manually above:
1. You shouldn't need to comment out configure_source as src2pkg should skip the step without problems or errors.
2. Instead of commenting out compile_source, use -m='make linux' ... (this will get written as MAKE_COMMAND='make linux' in the resulting script.
3. The Makefile for version 5.4 and 5.5 has no install rule at all so the install steps have to be written into the script. (The latest code I am using should actually find the nedit binary and install that, but it wouldn' know about the nc/ncl binary.
4. The installation of the documents not in the DOCLIST could probably be handled by including them in the DOCLIST(with the subir 'doc' included. I've already promised to rework the search for docs in the next release. Meanwhile, having the steps coded manually into your script is good anyway as it explicitly shows what's 'abnormal'(started to say 'wrong') with the source package.
Finally, I think you are using the BUILD variable improperly. What happens when you rebuild one or two of those packages? You'd have to change your conf file to get a new build number. What you can use is the SIG variable. Note that the way you are using the BUILD variable may cause problems with installpkg anyway because of the extra hyphens.
installpkg parsees package names from right to left and uses the '-' as the divider character. It will think the build or release number is 11, then the ARCH is slamd64 and VERSION is lpes and everything else to the left is package name! (Using underlines instead avoids this: 1pes_slamd64_11)
Still, I think a better way to handle this is by using SIG='_1pes_slamd64'
which will yield a package name like this:
For simplicity (and following usage of other package builders) I've put the signature *after* the build number. But a slight rework should make this possible:
Remember my hands are somewhat tied here because installpkg/upgradepkg use the '-' as the divider and won't be able to properly handle build number, name or version if we use any extra hyphens(-).
Thanks very much for the feedback as it helps to improve src2pkg for everyone.
Ahha! Somewhere in the back of my mind I had wondered about the incremental build numbers, but because so many packages change when the distro gets upgraded, I've taken some liberties with the naming ... let me try to explain:
A general package looks like this:
That is to say, <name>-<version>-<arch>-<build number>.tgz
But mplayer has a gazillion deps which are reliant on the underlying distro libraries. In the case of gtk+2 stuff, changing from 2.6.0 to 2.8.0 sometimes breaks things. Clearly not good.
So, I made a decision to make my package names more descriptive (i'm the only one using them) with regards to what distro version they were built on. "slamd64-11" refers to the stock 11.0 release of slamd64. It could be argued that the slamd64 part is redundant since I only run that distro, but I wanted to make sure i knew where that package could and should be used. I've built packages in the past, but literally only as a means to be able to uninstall/upgrade them; should I change the underlying libs I rebuild the package and because of the horrendous quantities of deps (in some cases) it's faster to just rebuild than faff trying to work out what works and what doesn't and fill in the gaps.
Anyway, you're perfectly correct in saying what I want is actually SIG, and the resultant would (for me) look thus:
I'll encorporate that asap.
FWIW slamd64 has removed the -m32 option from the toolchain due to gcj problems, I think. I can fish out details if you're interested. The point being is that compilation of src tarballs with src2pkg is 90% hassle free with the setup i have (although I'm still trying to fathom out the actual procedure from the functions include file), but taking a binary tarball and converting it to a slack package is ... trickier.
Anyway, on to the interesting part ...
By binary packages I mean just that - downloads of precompiled binaries with no install script or some custom install method. Basically for some things I'm too lazy to try and satisfy the deps for compilation and just run the provided binaries, vnc, nedit and rar are the major ones. VNC because i've had colourspace problems between a 64-bit Xvncserver an 32-bit vncviewer and rar because that's the only choice! I've no idea why i use binary nedit *shrugs*
Ok, I misplaced the VNC package. That one works fine.
# Any extra options go here
# Get the functions and configs
source /usr/libexec/src2pkg/FUNCTIONS ;
# do_all_processes can substitute these 16 steps:
Nevermind, heh. I have a script for nedit, but it doesn't work ... so I assume I built the nedit package some other way. I am so forgetful sometimes. Anyway, the major problem I had was with rar ...
Because of the way src2pkg copies things between the untarred directory and it's own build dir, I always lost the "rar" binary, so when running the install it b0rks.
# Any extra options go here
# Get the functions and configs
source /usr/libexec/src2pkg/FUNCTIONS ;
Found source archive: rarlinux-3.7.b1.tar.gz
Removing existing package build directory from previous build -
Removing existing source build directory from previous build -
Creating working directories - PKG_DIR SRC_DIR Okay
Unpacking source archive -
Found sources: rar
Moving into SRC_DIR: rarlinux-3.7.b1-src-1pes
mv: cannot overwrite directory `../rar' with non-directory
Correcting file permissions - Done
Skipping configure_source - Continuing since we found a Makefile
Correcting Makefile - Fixed mismatching arbitrary PREFIX
Tracking Installation - Logging: 'make install'
mkdir -p /usr/bin
mkdir -p /usr/lib
cp rar unrar /usr/bin
cp: cannot stat `rar': No such file or directory
make: *** [install] Error 1
FATAL! Running 'make install' has failed with error: 0
Try using 'make -i install' if this is a false error. Exiting...
rarlinux.src2pkg.auto FAILURE in make_install
I looked into the issue and while my scripting is pretty good, FUNCTIONS being the non-trivial include file it is, it will be faster for you to understand than me!
I started writing a "Why you should use src2pkg" guide, I'll finish that at some point and hopefully add some more bits from these discussions into the practical howto part. You'll be the first to see it =)
Sorry it's taken some other issue to bring this to light!
I started to ask if you meant (re)packaging pre-compiled binaries but decided that wasn't what you meant. Anyway, this feature is quite new so it can surely be improved.
I see some possible weirdness in the output above that has to do with the way tarballs are unpacked and renamed. In order to avoid guessing or using arbitrary name patterns, src2pkg directly creates the SRC_DIR, then unpacks the source tarball inside there. Then it cd's into the directory created by unpacking and moves everything up one directory and then destroys the original unpack directory. I was really surprised that I got it working as welll as it does with so many types of source/bin archives, but it can still fail or do the wrong thing sometimes. The 'decisions' are not really intelligent, but are based on the heuristics of what you would do in certain cases, based on experience with many hundreds of archives. It has become much more complicated than I ever planned it to be. (The original PkgBuild would *always* create a package no matter what happened!).
One thing to keep in mind is that the whole point of using any kind of build script is to insure repeatability. (A descriptive/narrative article which explains how to build a package would nearly always be longer than the script itself). The point of using functions is so that the scripts can be kept extremely short, making it easy to see when you have to do something different from the default.(This is why I abandoned the idea of just creating a 'generic' build script. Even with very minimal features a generic script quickly reaches 75-100 lines and it requires close study to recognize any unique code which might be inserted or changed between the standard generic code. A generic src2pkg script can be created with less than 5 lines.)
The FUNCTIONS files has indeed become non-trivial -I admire your courage for trying to make sense of it! Even I have to refresh my memory of what and how each function works when I have taken a couple of weeks off from coding, so don't feel bad.
The other advantage of using functions is to keep the code modular. When the default code or available options don't do what you want you should nearly always be able to comment out the function in the build script and substitute 'manual' code with nearly exactly the same sysntax as you'd use on the command line and without having to use/remember a bunch of variables. Only rarely would you need anything except SRC_DIR, PKG_DIR or CWD tacked onto the front of the regular command-line syntax.
So, in the case of packaging rar, just comment out configure_source, compile_source and fake_install and then insert something like:
This still lets you enjoy the convenience of the rest of the functions.
(I'm pretty sure that the weirdness with rar has to do with the unpack sequence -it enters a directory named 'rar' and tries to move the 'rar' binary up one level but can't because 'rar' already exists as a directory. I'll bet you can fix this by passing -s='rar' to src2pkg
(expressed as CONFIG_SUBDIR='rar' in the src2pkg script) and not have to do anything manually.
I'm extremely pleased that you use and enjoy src2pkg and want to write about it -that's why I discuss these 'philosophical' points. It would be good if you let me 'approve' what you write first -otherwise you may create more work for me (If I have to UN-explain to someone else something you wrote. I'm sure that your intention is to help. Writing documents is much more tedious and thankless than writing code. That's why the documentation is so poor right now -the program has gone through quite a transformation -to the point that I had to ditch all preceeding docs. I am getting close to real stability and consistency in the main features which will allow me start fresh with better docs.)
I really appreciate your interest, time and efforts.
I'm having a problem with installwatch when using src2pkg or checkinstall.
I'm getting that "ld.so: /usr/libexec/src2pkg/installwatch.so cannot be preloaded: ignored" error. It configures and makes ok, and then gives this error on all "make install" lines.
It's happening on my new Slamd64 11 install, and I'm using a 2.6.21 kernel.
First I installed checkinstall and it worked fine.
Then I installed src2pkg and it started giving me this error.
Now, even if I remove both and install one at a time it gives me the same error.
I'm not sure if it's related, but installwatch.so isn't in my ld.so.cache, even though I'm running ldconfig after each install of src2pkg/checkinstall.
I'm guessing that maybe src2pkg's installwatch broke checkinstall's installwatch, and vice versa. I remember reading about some problems when using them together, but, by the time I installed src2pkg I had forgotten about checkinstall.
Does anybody know how to fix it?
Is it trying to execute that in 32 or 64 bit mode?
I'm not sure what you mean by that. I'm using Slamd64, so my system is mostly 64 bit, but I'm using the regular tgz (32 bit) packages of src2pkg and checkinstall. I downloaded the 1.6.1 package from checkinstall, and I'm using src2pkg from the link you gave me
By the way, I just found out there's a Slamd64 package for checkinstall (and I could also build it from source), maybe I could try that and see what happens.
And, yes, both checkinstall and src2pkg don't work.
The copy of installwatch that comes with src2pkg won't bother checkinstall and will not be picked up by ldconfig either. It is installed in a completetly separate directory. Installwatch does not need to be in your ldconfig paths as the LD_LIBRARY_PATH is explicitly given when the installwatch/checkinstall/src2pkg are called.
I think the problem you are having is related to the installwatch and kernel version that you are using (if not also the usage of 64bit libs).
There is a later version of installwatch which is supposed to be better for use with 2.6 kernels, but when I got the sources from the developer thwere was a rejected diff file included which I wasn't sure what to make of...
There was a path-change among the other changes and I didn't feel like fooling with it at the time. Please let us know if the 64bit version of checkinstall compiles -I'll try to have a look at using the later libs version when I get back to coding.
I installed the checkinstall package from Slamd64-current and now it works.
Then, I tried copying checkinstall's installwatch and/or installwatch.so to /usr/libexec/src2pkg. Now ld.so doesn't give me the error from before, but src2pkg exits with the error:
FATAL! Running 'make install' with installwatch produced no files list
If you mean a previous src2pkg version, I have no idea, this is the only version I've ever had. I think maybe it's something about 32 bit vs 64 bit, like gnashley said, because this checkinstall package was built for Slamd64, and now it works. I guess maybe they changed something about the way installwatch works, and now src2pkg doesn't understand what this new installwatch is saying.
But it could also be the 2.6.21 kernel... I don't know.
I had some similar (ld.so cannot preload, etc..) errors with some E17 libs (hardcoded paths), but it was just a matter of creating a link to the 64 bit libs.