Src2pkg is one of the first things I install whenever I install Slack. Thank you for the great tool!

I wonder if it would be possible for the next release of src2pkg to include an option to create a .Slackbuild instead of a package?

Is this really true? I mean, Im new to Slackware, and have intalled many times from source with ./configure;make;make install.

Is it true that src2pkg makes this automatically? And if I want to remove, I just removepkg <package>? OMG... OMG...

Thank you so much!

Hey, is not a joke right?

it's true! it's true!
also it comes with a tool called trackinstall, which acts more or less like the good old checkinstall utility. But you most probably will just need to do

# src2pkg source-version.tar.gz

and voila -- you have a package in /tmp

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.

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.

3 members found this post helpful.

Im trying to build Mesa-7.11 driver package. However, I have some problems with src2pkg options.

I try to do this:

bash-4.1# src2pkg --config_command='./configure --with-dri-drivers=i965' -m='gmake' -i='gmake install' MesaLib-7.11.tar.gz

However, output shows that it takes only a part of my config_command like this:

Running user-specified CONFIG_COMMAND: ./configure --with-dri-drivers

Obviously, the most important one is missed, namely i965. Am I doing something wrong or is there a limit of config_command string?

*EDIT: So "=" symbol is ignored? Why? Gah,, what am I missing here...

Many thanks for a truly wonderful tool.

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.

Ah, thanks for the tip. It worked now, with "-e" option.

Thanks again for your effort with src2pkg.


/eXpander_

Take a good look at the text output just as configuring begins and you can see what all gets added in there.