In fairly short succession we have had at least three posts with (I assume new) users expecting to install non-Slackware packages with installpkg, pkgtool or slackpkg.

Just a friendly reminder for any newbie reading this.

Slackware packages are compressed tar archives. However, that does not mean that all compressed tar archives are Slackware packages. Nor does it mean that all packages are Slackware packages.

Slackware's packaging tools (pkgtool, installpkg, upgradepkg, removepkg and slackpkg) only work with Slackware packages. Unless you know that a given package is a Slackware package, do not expect Slackware's packaging tools to be able to handle it.

One fairly good hint with regards to if a package is a Slackware package is to look at the name. A Slackware package is typically named program-name-version-architecture-buildtag and ends with either a tgz or a txz extension (in theory it could also end .tlz or .tbz but that is unlikely).

These appear to be Slackware packages, based on their naming:

foo-bar-1.0-i486-2.txz
example-2.3-x86_64-1_SBo.tgz

These are not named like typical Slackware packages:

foo_bar-1.0.tar.bz2
example-2.3-Linux_x64.bin

5 members found this post helpful.

Well done!

My one complaint with Slackware, is that the documentation is not as good as it could/should be.

Prior to the thread in which you guys helped me out so kindly, I was under the impression any tar.gz could be handled by some of the tools you mentioned.

And I still don't know the difference between pkgtool; installpkg, and the like (Although I think, at least I have a handle on SBOpkg and Slackbuilds....)

I've read a lot of the documentation and wikis and such- but there doesn't seem to be anything which gives an overview of all the different ways of installing various packages, and when to use the various tools and or do it manually from source. It's more like: "Read a bunch of different things, and kind of assemble all the bits and pieces of information until you sort of kinda maybe have somewhat of an idea". It also seems that much of the documentation assumes varying amounts of pre-existing knowledge.

This is the only aspect of Slackware which is giving me a problem (But I'll learn...eventually-). Otherwise, I find Slackware easy and straight-forward. Making Slack my primary OS, I really want to be able to install third-party stuff (even though I rarely do so)- otherwise, I'll never feel confident, or self-sufficient. Lack of [or my ignorance of] a good comprehensive tutorial on this subject, is really the only thing, IMHO, which makes Slackware a little tough for noobs.

But thanks to you guys and this forum, at least someone like myself has a chance of figuring this stuff out. No way could I be using Slack, otherwise!

I'm using Slack, and I ain't going back!

You might want to start with this page to get a bit more background on the differences between the package management tools:

Slackware Package Management

1 members found this post helpful.

pkgtool is a front-end to installpkg and removepkg. It also lists contents of the installed packages and allows you to re-run the setup scripts that are run at the OS install time -- such as configuring the mouse.
I haven't really used pkgtool in 16 years of using Slackware - I use removepkg, installpkg directly, and see what packages I have installed by looking in /var/log/packages.

I can understand your confusion with thinking source archives were Slackware packages.
In summary, I think a reasonable approach is that if the package file names have an architecture in the name, such as
foo-1.0-i486-1.txz
foo-1.0-x86_64-1.txz
foo-1.0-noarch-1.txz

then they are Slackware packages.

If they have any other naming scheme, or you didn't download them from a page that explicitly marked them as Slackware packages then they are not.

Another way is to see if the package has a package description.
Let's check the glibc zone info package in the 'a' series.

Yes, this is a properly formed package.

Checking the bash *source code*:

No it isn't.

5 members found this post helpful.

Another tip to identify a proper Slackware package regardless of the name is to look for the install directory inside the package:

A valid package at least contains a slack-desc file, and sometimes a doinst.sh.

EDIT: Well, drmozes already mentioned this while I was writing...

1 members found this post helpful.

That does help somewhat. And I'll read some of the other articles it links to.

They always seem to leave out important details- like:

How does one know that WINE exists as a Slackware package- and the details to know the version and filename? This is the type of stuff us clueless noobs need to kno.

Also, the official Slackware packages are just the packages which you already get when you do a full install, right? So if you've done a full install, all the official repository is good for is updating or newly added packages, right?

[Before somebody punches me] I'm very slowly "getting" all of this. Other distro's easy, dumbed-down package management spoiled me, and kept me ignorant [But thank goodness they exist, 'cause I could have never handled this stuff 4 years ago when I was brand new to linux! I can barely handle it now ]

I think for the present, instead of concentrating on learning to compile packages manually, I'm going to work on learning to do the Slackbuild thing- and I'll have a head-start, having Maciuszek's awesome example in the other thread [ http://www.linuxquestions.org/questi...ll-4175507554/ ] to work from and use as an example!

FYI other 'package' files are very similar, you can rename them to .tgz and then untar them and find the program files set out in a formal directory structure with install scripts, etc. very much like you get if you untar your slackware package. Java .jar files are the same, except using zip instead of tar, and the same is true of MacOS 'application bundles' as well. Even windows does essentially the same thing even if it's a little overcomplicated in implementation.

So package files in general are just a special kind of archive file, with the files that need to be installed along with metadata concerning how to handle them. If you are familiar with the conventions of a particular package format you can unzip it instead of installing it, see what files it includes, where it wants to put them, what commands it wants run, etc. And if it's in a standard format, a .tgz or a .zip file, you can use all the standard tools that you could use on any other file of that type to, e.g. recover a corrupted archive.

Well, only if you ignore RPM.

1 members found this post helpful.

Wow! I like that! I think that is what Maciuszek did in the other thread [http://www.linuxquestions.org/questi...ll-4175507554/ ] where he essentially found the program I wanted to install in the Arch repository, and made a Slackbuild from it.

One question: How can one search the repos of other distros, and download their packages?

Shott answer: you shouldn't, as alien packages can't be used on Slackware but a few exceptions. There are tools to convert packages from a format to another (content and format of Debian or Fedora packages for instance are not those of Slackware packages), but very often the installation won't succeed or the application will not run because of dependencies issues or software versions mismatches.

An rpm is also just a compressed (cpio) archive with some meta-data tacked on the front. You can extract it with bsdtar (included with Slackware)

bsdtar will also open zip files and most other common archive types.

1 members found this post helpful.

No need to rename them at all.

2 members found this post helpful.

If you look at the thread that sumguy linked to, Maciuszek did not suggest taking an Arch package and installing on Slackware. He looked at the build and packaging script that Arch used for the application in question and took clues from it to hand craft a SlackBuild equivalent.

This use case is fine and indeed could save a lot of headache when packaging difficult applications.

@sumguy: https://aur.archlinux.org/ search for the package in question and then read the build script (PKGBUILD). The AUR (Arch User Repository) is like SlackBuilds.org and hence has packages outside of the main repositories. For packages that are part of Arch use https://www.archlinux.org/packages/. When you find a package click on "Source Files" and then read the PKGBUILD.

2 members found this post helpful.