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.
I just downloaded and tested. Wow... Just wow. Exactly what I was looking for. No need to worry if I should save my "make" folder or not, often I just deleted the folder, and then when I need to uninstall I need to do it manually. Or rewrite with a new update.
Now, everything is on the same place /tmp. Perfect.
Thanks guys, Love Slackware, Fornicate Windows.
Last edited by XavierP; 08-12-2011 at 09:50 AM.
Reason: Sanitised for your health, comfort and well-being
Yeah, it's no dream, but it's also no magic wand. There will always be some sources where you need to supply some special config options or turn on or off some feature of src2pkg to get it to do what you want. But, when using a recipe(*.src2pkg build script), you can do just like in SlackBuilds and simply insert manually-written lines of code or comment out any of the standard steps that src2pkg performs. You can also use to to convert packages between any of the supported package formats (excpet for converting *from* slitaz *.taz packages). And you can use it like gentoo's emerge by having src2pkg install the packages as you go.
@psionl0, that sounds like a good idea -but it's not a new idea. The trouble is that src2pkg is able to do what SlackBuilds cannot -it can track the files/dirs/links created (wherever they try to place themselves), and then put them in the 'right' place. For many packages built using a SlackBuild, you must code the installation manually to avoid doing 'bad' things. With src2pkg, it 'catches' the 'errors' automatically and fixes them for you. While AlienBob's SlackBuilds include the optional use of installwatch, src2pkg uses a forked version of installwatch (libsentry) by default, or some other method when even that doesn't work. To replicate that behaviour in a SlackBuild, you'd have to use installwatch by default and actually *do something* with the output and/or use one of the other 'safe' methods used by src2pkg, like chroot+unionfs-fuse. You can use the included tool 'sb2sp' to convert a SLackBuild to a *.src2pkg script, though... Or xou can use src2pkg to 'convert' your packages built from SlackBuilds to check them for any weirdness -just give package.txz as the source and have it convert it to package.tgz -it'll say something if it finds any problems -like unusual(possibly faulty) perms or ownerships, presence of questionable files or dirs -hidden files, your $HOME or anything like that.
solarfields mentioned trackinstall, which is indeed like checkinstall -without the drawbacks of checkinstall. But there is also another tool included called 'tracklist'. What it does is simply pass the 'make install' or other command to sentry(installwatch), without doing any of the many corrections which src2pkg famously does after package content is first created. But, unlike using installwatch (or even sentry directly), tracklist parses the logged output of libsentry and gives you a neat list of everything done by the commands you gave. Particularly, it will show not only dirs, files and links created, but will also show anything which was removed, renamed, chmodded or chowned -note well that the old installwatch will not detect these at all. You could use sentry instead of installwatch with SlackBuilds, by simply linking installwatch to sentry, but the standard scripts, as said, don't do anything at all with the logs generated. STill, doing so would give you a more complete list of what happens when the commands are run -I guess you could split the log-parser out of tracklist and use that to get a clearer picture of what happens.
I've built a whole distro using src2pkg scripts, so anything is possible.
eXpander_, I haven't seen that sort of error for awhile -a lnog time ago there was a problem with having extra '=' chars in there. But, you are overdoing it by using CONFIG_COMMAND anyway. The default CONFIG_COMMAND is './configure', but options and settings get added to that for final usage. You don't have a prefix in there, so you would wind up with /usr/local which you probably do not want. Whether you specify the CONFIG_COMMAND or not, src2pkg adds the default prefix '/usr' (or what the conf file/build-script says, and then adds EXTRA_CONFIGS after that.
So, what you really want is:
src2pkg -e='--with-dri-drivers=i965' -m='gmake' -i='gmake install' MesaLib-7.11.tar.gz
That way your prefix gets added in. Actually, since gmake is a link to make, you only need:
src2pkg -e='--with-dri-drivers=i965' MesaLib-7.11.tar.gz
Try that and see if it works. And I'll try and have a look whether something is wrong in that routine -you should be able to treat CONFIG_COMMAND just like INSTALL_LINE, where you get to specify the whole thing explicitly. But, it's better to only specify the parts needed -that is what is really needed to make the build 'tick'. Remember, you don't even need to specify --prefix as it will be added automatically. Also, --libdir will be added automatically, according to the ARCH you are building for. If on multi-lib x86_64 and you want to build a 32-bit package, use -M32 in your options -src2pkg will take care of all variables which need to be adjusted -including libdir, LDFLAGS and pkgconfig file locations.