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
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.
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.
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 :)).
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!
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.
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.
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
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
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).
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.
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)
|All times are GMT -5. The time now is 08:50 PM.|