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.