make your own slackware packages!
 

Hey, I just learned how to make your own slackware (.tgz) packages!

It pretty simple really.

1) get the program and unzip it. Ill use gaim as my example.
tar -zvxf gaim.tar.gz

2) do a ./configure && make in the console.

3) now you do a make install DESTDIR=/tmp/package
(this sets the install directory to /tmp/package.

4) change directories to /tmp/package
cd /tmp/package

5) type makepkg -l y -c n ../gaim.tgz

after that is done, go back 1 directory and gaim.tgz should be there!

6) installpkg gaim.tgz

yeah! now not only is this program installed, but its in pkgmanager also. so deleting programs is much easier.

also, if you keep the slackware package, it takes seconds to install it instead of minutes.

have fun!

so after you do all that is it safe to delete the source files/tarball?

Is there a significant size difference between the tarball and the package?

actually, there is. take wine for example, in tar ball, its 7 megs ZIPED.. in tgz, its 11 killobytes!!!! and it works!

Just so you know, Slackware packages ARE tarballs. There is
no meaningful difference between the packages that someone
calls a "slackware package" and one that is called a "tarball"
except that the slackware package contains some additional
information of what to do with the files that are packaged up. This
information is in a file called "install/doinst.sh" that is created
when makepkg forms the slackpack. That's pretty much it.
man makepkg
man pkgtool

Also, There is no known mathematical way to compress something from 7MB to 11KB, unless every bit is essentially the
same. So, even if the slackpacks were not the same thing as
tarballs, either you're missing a hell of a lot of files in your
"Slackware package", or you mistook the 11MB for 11KB.

The only problem with that is that the package that you create is system specific. It has been (dynamically) compiled on your system, hence it's using the libraries that you have. That is, if you want to use it on a different computer, you will have to have the same libraries you had at the compile time.

If you're thinking of distributing packages I suggest you either compile statically (which is when you compile the support inside the executable instead of linking to libraries), or have a very generic setup on your system using older libraries which are more likely for people to have.

If you're just building packages for your own use, then this is avery cool as it will allow you to install/uninstall programs when you feel like it. Easier than using rpm if I might add (don't tell the RH fans I said this :)).

The only thing you're missing is the fact that source tarballs contains files that contain text, much of which is NOT used in the actual binary executable file (make scripts, documents, portability stuff and such), while the package that he created only contains the finished compilation. :)

Hey - I think it is cool, what do the -l and -c do ?

For this job, i use the little program 'checkinstall'. Works fine here!
http://asic-linux.com.mx/~izto/checkinstall/

yea, 7mb into 11kb, lol....had to be mistaken...on a dial up that a difference of a 3 second download to a 25 minute download.

The Wine binary (for example, since that's the one he used)
by itself only compresses to 47 kB. If you include everything else
required by wine to actually run (libraries, man pages, etc.), you
will hit MB rather quickly.

A mistake was made either in the reading of the number, or the
creation of the tarball. A slackpack is always going to be a
bit larger than a tarball containing the same binary files (libs,
executables, etc.) because it also has to contain the scripts that
tell the package manager what to do with those files. It may not
be as large as a source tarball, but there is a limit to how much you
can trim off before you have nothing useful.

There is a big difference between a Slackware package and a source tarball, namely that the Slackware package contains binaries that have been zipped up into a tar.gz format, and the source tarballs contain source code that has been zipped up into tar.gz format.

It is quite common for the compiled binaries to be much smaller than the original source code, since the code contains all kind of stuff that isn't folded into the binary. As a matter of fact, just today I downloaded both the binary and the source packages for OpenOffice.org 1.0.2. The binary is about 71 megs, and the source package is about 172 megs.

The only similarity between a Slackware package and a source "tarball" is the compression scheme.

BB

A slackware package can contain whatever you want it to
contain. All you need to do is build your install/* and
var/log/setup scripts to do what you need. If you want to
distribute source as a slackpack, then do so and write your
doinst.sh, setup.*, etc. to do what you need them to do
(configure, compile, install, make clean, etc.). Theoretically, you
could even create a slackpack that just contains scripts to
connect to some server somewhere, download the files it needs,
compile them (if necessary), install them, and then clean up after
itself.
A Slackware package is NOT limited to precompiled binaries.

The point I was making in my previous post was that the claim
that the wine package went from 7MB to 11KB was bogus, either
because ratbert90 misread the filesize or didn't put everything
in the tarball. The compressed wine binary itself is larger than
ratbert90's purported size of the entire wine slackpack. I don't
claim that ratbert90 was not telling the truth, just that there was a
mistake made.
The post before that about compressing down from 7MB to 11KB
being impossible still stands. If you can show me an algorithm
that will allow almost 1000X compression of BINARY (hah, even
non-repetitive text) data, then you could be a very rich person.
If the new size of the tarball is really 11KB, then data is missing.

No, I'm not defending the miraculously shrinking Wine binary... that is certainly extreme. Also, you are correct that you can use makepkg to do anything you want. pkgtool is not strictly limited to Slackware, just as you could also use apt-get to keep your Slackware distro up to date, if the configuration stars were all aligned.

However, I think of a "slackware package" as something found either in Pat's binary tree, on linuxpackages.net, or what you can make yourself after compiling.

Have you ever seen a Slackware package that was like a Gentoo script (download/compile/install)? Such a package would indeed by a bit larger than just the source code zipped up, as you originally said.

The original poster made an excellent point that making a package out of freshly compiled software is a great way to keep tabs on your system. Someone else asked if you would save disk space relative to keeping the source around, and my point was that you do (overly optimistic claims notwithstanding).

Cheers,
BB

edit: Oh, I forgot to mention the main point of my reply. My statement about the difference between source tar.gz and slack tar.gz was not really intended as a counter-point to moses. Rather, I've seen many newbies confused about what to do with this "tarball thingy." The answer is, well.. it depends. You need to be aware of when to do tar -zxvf and when to do installkpkg.

I guess my point (which was never stated as such) is that you
really need to be careful of what you are putting into your own
personal package before you start deleting things. Clearly a
mistake was made with the wine "repackaging", and if care isn't
taken, when the wine install is removed (for some reason), and
an attempt to reinstall it using the above package is made, it
won't work. Thus, the claim of a slackware package being
1000x smaller than the source tarball is dangerous -- it may
encourage people unfamiliar with compression and slackware
packages to try to achieve such space saving without really
knowing what they are doing.

well, look into something called heaven7 on google (it's for windows though)

it's a 64k file, that when run uses about 34 megs of ram (i dont know if it comes from the file though, but it definetely doesnt come from the net)

I don't see what Heaven7 has to do with compression of data.
It's easy for a program to allocate almost any amount of RAM
that isn't already allocated by the kernel (or other programs). I
can write a few line program that trys to fill all available memory.

Compression of data is using an algorithm (i.e. lzw, LZ77,
Huffman,etc.) to find common patterns, and replace those
patterns with a description of the pattern that takes fewer bits
than the original pattern. It's the same sort of thing that JPEG
and other image file formats use to make the image smaller,
EXCEPT that DCT (one of the most common JPEG compression
algorithms) and most other image compression algorithms are
lossy meaning that once a file is compressed, you can never
recover the original data (from that compressed copy). LZW, etc
are lossless, which means that though all data can be recovered,
it doesn't compress as well.

From the man page of gzip (obviously uses a lossless algorithm):

Here are the results of my recent build of openbox-2.3.0

1. 496k openbox-2.3.0.tar.gz (source code, zipped)
2. 4.2M /tmp/openbox-2.3.0/ (source directory, pre-compilation)
3. 28M /tmp/openbox-2.3.0/ (source directory, compiled)
4. 8.9M openbox binaries, compiled with no options
5. 3.5M openbox-2.3.0.tar.gz (slackware package created from #4)

So, you can see that there are serious disk-space gains from compiling software and putting it into a Slackware package vs. keeping the compiled source code around. You would save the most space, obviously, if you just kept the source code tarball, but then you'd have to recompile whenever you wanted to re-install the package. The advantages of making a slackware package, other than space, is that you can easily remove it with pkgtool, and you can easily reinstall it without re-compiling.

As someone else said, your package will generally only work on your system, unless you take pains to keep it generic.

BB

So how do you get a "package description" then ?
 

This is going to make me look a prize idiot, but I've read man pages till I'm blue in the face and got nowhere, here goes.

When you make a package with "makepkg", EXACTLY how do you tell it what to put in the "Package Description".

The packages I make can be used on the same computer if I have to reinstall everything, right?

That would be really useful for easy backup and restoration.

I don't know what went wrong, but I followed the steps given.
In my case I am trying to create a 'samba2.2.8a.tgz' package.
My creation directory is '/D/creation'

1. unpacked samba-2.2.8a.tar.gz
2. cd D/creation/samba-2.2.8a/source
3. ./configure --with-smbmount
4. make
5. make install DESTDIR=/D/creation/package
(I made a directory called 'package' inside 'D/creation')

What happens is instead of installing everything into
'D/creation/package' ,it just installs the program as normal.

So as you can see, this did not work for me.
I don't know if this makes any difference, but I do have the
"checkinstall" package installed. I don't think that should
make any difference though.

The reason that I tried this posted method, is because I could not get a full install with the package that I made with checkinstall. It would not install all of the files into 'usr/local/samba/' . One very important directory 'lib' is not even installed by the '.tgz' that I made with checkinstall.

Well, this sucks. The whole reason that I wanted packages in the first place was so that I can have a clean machine, with removable software. Now I have samba-2.2.8a installed and I don't know if I can remove it. Right back to square one.

JC

I wonder why makepkg doesn't have an option to specify the path; it's strange you have to cd…
thanks for the explanation though

Not every Makefile honours the DESTDIR option. You need to examine each source individually to see if any special tricks are involved.

It is also best to try and make the package as a normal user before doing so as root. The Makefile might make system changes (eg change rc.M) that you weren't expecting and that would make removing the package very difficult afterwards.

My blogs describe making packages and creating scripts to make packages. They also contain links to SlackBuilds.org where there are more discussions about what to do if DESTDIR is not honoured.

In a lot of cases, src2pkg will do all the work of creating a package for you.

I think this thread qualifies as an exhumed corpse...

I didn't see the dates on this thread. Maybe there should be something like [NECRO] next to the title of old threads (in the same vein as [SOLVED]).

Nine year old thread? It's a record. The oldest I've seen previously was eight years old.

Hey, cut the guy some slack. Archaeology is my name for it.

Reminds me of a Randy Travis song.

"I'm diggin' up bones - I'm diggin' up bones......Exhuming things that are better left alone..."

The concept of necroposting doesn't apply to Slackware. It works more or less like in 1992.

I wonder if the OP is still present at the forums. It might be interesting to hear about his experience with Linux since then.

Especially since the OP is 100% valid today.

The fact that there are now more ways to automate it notwithstanding.

Ha! Nothing like a blast from the past.

I couldn't help but adding my two cents' worth here, it might be useful for others. Don't forget slacktrack, which is another utility for making a slackware package when DESTDIR doesn't work. I used it recently to make a package out of the texworks editor (just to try it out). The usual method (essentially that of the OP!) didn't work because DESTDIR was not honoured.

I was able to make a package (lazily) by doing the following:

• obtaining the texworks source tarball: texworks-0.4.5-r1281.tar.gz
• in the same directory as the tarball, I created a basic little build script tw.build:
  
  
  Code:

  ---

  #!/usr/bin/bash

tar xf texworks-0.4.5-r1281.tar.gz
cd texworks-0.4.5
qmake
make
make install

  ---

  which ordinarily would have compiled and installed texworks ``directly'' onto the system, i.e. bypassing slackware's package management tools.
  
• from the same directory execute, as root (after logging in with su - to get the proper PATHS setup, etc):
  
  
  Code:

  ---

  slacktrack -p texworks-0.4.5-i686-1custom.tgz ./tw.build

  ---

...and a beautiful new home-made slackware package appears at /tmp/texworks-0.4.5-i686-1custom.tgz

Michael

PS I couldn't resist giving slacktrack a plug here, given the contribution of moses (slacktrack's author?) to the original thread so long ago...I guess that was pre-slacktrack!!

Wow, thanks! I can't believe I'd never heard of slacktrack before!

You're welcome Geremia, I'm glad you found the post helpful! I must say, it took me quite a while to work out what/how slacktrack is/works, it was a bit inaccessible. But I came across the following set of slides from a talk Stuart Winter gave on slackware packaging:

http://www.slackware.com/~mozes/docs...esentation.pdf

...and it helped me understand it a lot.

Cheers,

Michael

Here's the list of DESTDIR-like syntax which src2pkg supports automatically:
CMAKE_INSTALL_PREFIX DESTDIR BUILDROOT INSTALLROOT INSTALL_ROOT INSTALL_PREFIX install_root instroot DIST_ROOT

If anyone knows of any more, I'll happily add them.

I use "spill" rather than create Slackware packages.

http://www.rpcurnow.force9.co.uk/spill/

"spill is a program for creating set of symbolic links from one directory hierarchy which point to corresponding filenames in a separate directory hierarchy. It's primary use is to allow packages built from source to be installed in separate directory trees, which are all linked together under a common directory tree (e.g. /usr/local) to reduce the length of the PATH environment variable. "

"Spill" is not a part of Slackware and isn't included in SlackBuilds.org so I can't use "spill" to install "spill". ;)

More seriously, "spill" seems to assume that all configure files honour the --prefix option. You can't really afford to make any assumptions about a source. Each source needs to be treated as potentially a special case.

I'd like to blow my own trumpet here:

mkslack - a SlackBuild generator script
(C) David Woodfall
(C) modifications by slakmagik

This slackbuild generator uses templates stored in /usr/share/mkslack/templates and a config file /etc/mkslack/mkslack.conf which you must edit for name, email, copyright etc.

http://www.dawoodfall.net/files/slac...rsion/mkslack/

There's also src2pkg, of course. :)

gargamel