I have a couple of related questions about installing slackpacks, installing tarballs, using rpm2tgz and using pkgtool.

I installed Bluefish last night. I downloaded bluefish-0.9.tar.gz. I tried to use pkgtool and installpkg to install, but they wouldn't do the job because the file was not a .tgz, it was a .tar.gz. So, being the newbie I am, I thought a .tgz = a .tar.gz, just different naming convention, so I just renamed the file so it had a .tgz extension.

Well, pkgtool/installpkg would now take the file, but it didn't install bluefish. As far as I can tell, it unzipped and untarred it and that's about it. I had no trouble with ./configure, make, make install, but then I got to wondering what's in a .tgz file that's not in a .tar.gz file that makes it work with pkgtool? Is there something that's configured especially for Slackware in a slackpack (.tgz)? Are all .tgz's slackpacks or do you run across .tgz's from time to time that aren't built specifically for Slackware?

These questions also made me wonder about the validity of downloading a .rpm built for redhat (e.g. bluefish-0.9-1redhat.i686.rpm) and using rpm2tgz to convert it to a .tgz. Would I get a .tgz that Slackware would be happy with and be able to install with pkgtool? Is this advisable?

I have no problem going the ./configure, make, make install route, but I prefer the pkgtool/installpkg method if only for the convenience that pkgtool keeps track of all the packages installed.

Any clarification on the above subjects is appreciated.

AFAIK all slackware packages end with .tgz, but not all files that end with .tgz are slackware packages. Inside a slackware package .tgz are the already compiled binaries and a few extra files, most notably install/slack-desc and install/doinst.sh. The pkgtool looks for those files after untarring/gunzipping the .tgz, and does the magic based on that info. A .tgz that has source code and makefile is not a slackware package, it's just a gzipped tarball. The rpms also contain already compiled files, and other special description and installation files. (RPM is Redhat Package Manager). There is a section in the slackware book that gives more details about using/building slackware packages:

http://www.slackware.com/book/index....rce=c3984.html

HTH,
-bbeers

Oh, another thing that is a sure sign that the .tgz is a slackware package is that it usually has a name like tool-3.2.1-i386-1.tgz, where the name of the package is tool, the version of the tool is 3.2.1, the architecture that the package is compiled for is i386, and the version of the package itself is 1. So jims-tarball.tgz is likely not a slackware package, but dhcpcd-1.3.22pl1-i386-3.tgz is.
And sometimes you'll see SRPMs which are Source RPMs, just to keep you on your toes. :-)

-bbeers

Thanks bbeers, very, very helpful.

One followup, say you get an rpm that contains the compiled binaries for a Red Hat distribution. You run rpm2tgz and get a slackware package.

Talking about rpm2tgz, the Slackware Book says, "We provide a program that will convert RPM packages to our native .tgz format. This will allow you to extract the package (perhaps with explodepkg) to a temporary directory and examine its contents."

Is that really all that you can do with the resulting .tgz, examine its contents? What would happen if you tried to installpkg on it instead? Would it install and run, but just possibly be quirky? Or would it definitely not install and not run. I mean, they are binaries compiled for a totally different distribution which may have different libraries, compiler, etc.

The red hat rpm are made to fit in a red hat system, where to put all files . . .
So if you are trying to fit the content of a red hat rpm , you have to know where Slackware expects the files to be.

But if it's just the binary file / programe file you want then I guess you can at least 'explode' the rpm and grab whatever you want from it.

1: ready to run slackware packages
2: sourcecode (./configure , make , make install )
3: fiddling with other packages.

Yeah, depends entirely on what is in the rpm. Sometimes a binary is portable enough to run on your distribution and sometimes it's not. But the installpkg thing won't really install it as intended because the scripts are for a RH distribution and may not make any sense on slackware. After doing explodepkg or just 'tar zxvf' of the result of rpm2tgz, you can examine the contents and install or run it where you like. There is also the possibility that you can just rpm -i the rpm and it _might_ work. SRPMs end up okay, because you're going to compile the source into binaries on your machine anyway.

-bbeers

OK. Thanks for the explanations.

I am surprised no one mentioned checkinstall .

It allows you to do the configure,make procedure and then make a slack package out of that which u can install. That way you can uninstall it - and keep a copy of the compiled binary package.

Hope this helps.

Right, checkinstall (version prepared for Slack may be found in "extra" directory on Slack ftp) is a really usefull tool, I use it constantly and newer had problem with install or uninstall of packages prepared with it. It is one of "must have" tool in Slack. And, last but not least, it is very easy to use even for newbie, not any special knowledge required.

Thanks shreev and Waldi!

checkinstall sounds like a very useful utility. I'm going to get it now.