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.
dugan, i think you have to create that link manually -I mean by putting this line after the line:
( cd $PKG_DUR/usr/bin ; ln -sf mplayer gmplayer )
That should take care of it. The line to create the link when the package is installed will be automatically put in the doinst.sh for you.
Ilgar, that looks like an old problem that keeps coming back to haunt. I think it is probably fixed in the upcoming version. the problem is with how to tell when an install rule really exists. You can't simply grep for 'install:' in the Makefile, makefile, GNUmakefile or other named makefile. First of all, it can be written any one of four ways in those four named files. But, many times a Makefile will have a line like:
include mk.conf or any other name, which actually has the install: rule in it.
Then there is the problem of detecting the M(m,GNUm)akefile in the first place, or accepting it as an argument like src2pkg -m='make -f makefile.unix'. And then sometimes you use some sort of command instead of 'make' which doesn't use any sort of file close to a Makefile.
I finally worked out a way to run $MAKE_COMMAND $MAKEFILE with the '-n' option if the MAKE_COMMAND is 'make' or 'make something', and then check the return status. If no error is returned then it appears there is an install: rule and then the command is run for real (-n tells make to not really perform the commands).
So, it gets very sticky trying to figure out if there really is an install rule. And trackinstall is at a disadvantage there, because it doesn't run configure for you. The routine/routine named configure_source is where most of the detection is done where src2pkg figures out what kind of sources they are and what files are there.
I'll try to check that particular source out and see if it is working here on the development version of src2pkg. Another disadvnatage with trackinstall is that I don't use it on a daily basis like I do src2pkg, so it's easier for bugs to slip under the wire. Still, most of the code is exactly the same no matter which you are running, but there are exceptions for trackinstall, too.
I'm downloading the sources right now to check it out. Any special configure options you used?
Ilgar, I tried building that here and didn't have any trouble doing it with either src2pkg or trackinstall. Are you actually getting a Makefile when you run ./configure? And does it compile without errors?
If so, and trackinstall still does not work, then that is because the routine was still not working so great in src2pkg-1.9.6.
Seems to be fine here with src2pkg-1.9.7-10 (what you are running was released last February... I gotta get this new version out the next few days.
Still, isn't 'src2pkg -W gtk-recordmydesktop-0.3.8.tar.gz' easier anyway?
I was using version 1.9.6, is 1.9.7 available somewhere? And yes, I do have a Makefile and as I said earlier, 'make install' works. So it must be the problem you mentioned above, i.e. the detection of the "install" rule.
It's changing the habit that's difficult . But seriously, what I do is to run './configure --help' first and see if there are any interesting options and run 'make' afterwards. Then I only need a 'trackinstall'.
As for using --prefix=/usr, it is my inetrpretation and judgement that that is where *packaged* software should go. But if you wanna change that, put another default in /etc/src2pkg.conf or just use the -p='usr/local' from the command line. src2pkg makes it easy to override any settings you don't like, usually either from the command-line or in a NAME.src2pkg script (for case-by-case control), or in the src2pkg.conf file for 'always' settings. There are so many configurable things that I try to not boggle your mind with 100-150 command-line options. Only the most useful, necessary or often-used options can be easily set from command-line.
Thank you for the thorough response gnashley. As I am a-day-old user of src2pkg, I've been browsing the help/FAQ/HOWTO documents and skimming over options and I can quite honestly say that src2pkg is indeed much more comprehensive than all the package management tools for Slackware I've seen although I am still a novice who is trying to get back to Linux after 18 months.
In any case, you mentioned that --prefix flag can be set in `/etc/src2pkg.conf' globally but I didn't see any option available for it. Does the format of the `src2pkg.conf' dictates to use a simple <FLAG=value> (i.e. PREFIX=/usr/local)?
In your conf file, it is best to use syntax like this:
[[ $PRE_FIX ]] || PRE_FIX=/usr/local
This sort of usage will still let you override your preferred default on a package-by-package basis.
If you look in your cond file now, you'll see line with similar syntax like:
! [[ $VAR ]] && VAR=value
But the new release is changing that casic syntax to:
[[ $VAR ]] || VAR=value
So, you might as well get used to the new syntax. They are interchangeable iin src2pkg-1.9.6, but 1.9.7 wil only be able to use this:
[[ $VAR ]] || VAR=value
Nearly anything you set in your conf file should be set like that, instead of using simply:
The latter will not allow you to change the value from the command-line or in a script, when needed.
Ilgar, 1.9.7 has not been released -I have sent pre-release copies to a couple of people, though. If you would like to receive a copy through email, send me an email and I'll send you a copy of the devel package, although I think I'm pretty close to getting the next release out.