I use swaret to get slack packages. But I use 10.2 so that isn't updated (much? I think its only security patches or soemthing).

For other software I use make install, but the other day was introduced to make checkinstall so I am trying that out now.

Well if i can find a package in LP that fit my needs i install it using installpkg otherwise installing from source is quite common although most of the time i forget to checkinstall instead of make install

Like koloth if I can find a tgz I install with installpkg. Rarely I use rpm2tgz and installpkg. Otherwise it is compile from source and make install. I was not even aware of checkinstall.

I use my own Slackware buildscripts most of the time. There are just a few exceptions where I didn't manage to get the sources compiled and where I rely on linuxpackages.net, alienbob's buildscripts or slacky.it. I download the security fixes for Slackware's stable release manually and install them in CLI.

I started with linuxpackages.net and then checkinstall but was always attracted by the idea of buildscripts. I didn't have too much problems with checkinstall, but I really like to compile and install a new version of my preferred apps in a glimpse, once the buildscript is complete. This way I could also better understand where the files go and overcome my fear to look into a Makefile to fix paths

i'm for compiling for frequently used programs (mplayer for ex.) and getting a pkg from lp.net, for an occasional depedency.

Like many others, I use SlackBuilds. They are the fast way to put together a package once you get the hang of them. I do run into software that I have to build by hand but makepkg works just fine for them. If SlackBuilds didn't exist, I would probably use checkinstall.

MagicMan

I'm a newb when it comes to Slackware. So, for the whole two weeks I've used it most things have been installed via a .tgz found on linux packages or the slackware site.

Although, once I saw this post I did a "makepkg" for my last program. It was an easy one with no dependencies.

Thanks for the thread it's been helpful.

mostlty i make install all my programs if there is no bleeding edge slack package of it. so i have my test-server running a bleeding edge distro on it and my desktop an nigh-bleeding edge distro (testserver isnt accesible for anyone due to bleeding edge cons )

I just like the tarbal package from the homepage of the software, so
would be more suitable for me.

make install is really the best, most stable and guaranteed way to get software installed. It's also the easiest.

I make packages only for software that I know I will eventually have to upgrade/remove, which is exactly 32 packages. I make almost all of them with a basic make DESTDIR=/work install, cd /work, and then fine tune the package manually, and run makepkg.

The only problem with that is when software requires special doinst.sh files other than symlinks, and I usually have no idea what that software wants to run(scrollkeeper-update) for example, so making packages for that software is often unreliable, so make install is again the best option.

Checkinstall I would only use on very small libraries, as there are too many things that checkinstall can miss.(ALL static libraries for example)

I like the ultimate control of having a SlackBuild, so I usually do my SlackBuild scripts even when the software is available at linuxpackages, slacky, {name your favourite software repository for slackware here}. With just a few exceptions (usually when I'd enter a dependency tracking hell).

I'd really love it if people at linuxpackages included their SlackBuilds (I know there are some who does, but they are few). It can be really usefull as a way to check the configure parameters or maybe a missing step in the installation, or something like that.

All of the above (except swaret) depending on mood, availability, time and phase of the moon

I've been adding features to my PkgBuild program and summarized some of the features this way:

- Safe package making. 'make install' is always tracked using the
installwatch libraries. Any files on your system which would be
overwritten are backed up first and restored nearly immediately,
even before finishing package building. And package making should
"leave no files behind" which are installed by 'make install'.
PkgBuild doesn't trust DESTDIR or 'make_uninstall' - comparing
files lists quickly shows that *many* Makefiles will fail to
fully uninstall the files that they install.

- Saner packages. PkgBuild corrects several common installation errors
and performs several sanity checks during package building. Special
attention is paid to slack-desc files to insure correct installation
and removal using installpkg and removepkg.

- Easier packaging. Most software can be built by
filling in just 4 variables in a simple script template which has
only 8 lines of code. Packages which require special treatment or
additional code are easily handled using another script template
which divides the whole process into 16 steps which you can customize.
Even this scripts has only 23 lines of code!

- Repeatability. PkgBuild takes you all the way through from directory
creation, unpacking of sources and building the package and cleanup,
all summed up in a small script which is easy to read, edit or port.

- Better build documentation. PkgBuild can produce many kinds of reports
and database files as well as logs. The PkgBuild script provides a
very 'clean' palette for showing anything unusual that's done to compile
the program or build the package, without having to wade through dozens,
or even hundreds of lines of script code.

- Better Package documentation. PkgBuild accepts your document list or
builds a default set of documents, in addition to whatever the source
code installs. PkgBuild *corrects* badly-installed doc directories and
man-pages. Better docs means better GPL conformance.

- Ease of scripting. Even beginners will find it easy to start making
their own packages. I'ts very easy to port other build scripts as you
usually will only need a few lines from them in the worst case. Many
times you won't need them at all.

- Easy oragnization. PkgBuild lets you do everything in one directory, or you
can specify individually where sources are located, where to unpack them,
where to build the build packages and where to leave them. Even the
build scripts themselves can be in their 'own' place. Automated building
and 'Group Builds' are also easy. I've used this to build nearly
a hundred packages with a single command.

- Flexibility -nearly everything becomes either a function which can be
skipped, or a variable which can be overridden at any point.
'noarch' packages and 'unusual' sources or packages are easily handled.

- Source Compatibility -PkgBuild automatically handles some source tarballs
which don't use autoconf/automake, like simple sources with an included
Makefile and packages which use Imakefiles. GNUmakefiles are also handled
appropriately.

- Diagnostics -PkgBuild provides tips and 'notices' all through the process
and if configuration or compiling fail, searches the sources for dependency
information and shows it.

- Visual Cues - All prompts are formatted and if you use 'quiet' mode and leave
the color on, you'll have an ouput that can be understood even if you are not
right in front of the screen. If you hate color, turn it off.
Script templates are also laid out to make it *very* easy to see what has been
changed, and where, how & when the changes are made.

- Extendability. Most of the features you think are missing have been considered
and are allowed for someway. Modularity of the code makes it very easy and relatively
fast to extend. For instance, this only needs a few paragraphs of code to be
made completely drag-n-drop for a majority of software! I restrain myself from
doing this while there are still more important things to refine. Also because
it must also write the script for me, since we are *all about* keeping a record
of this build. I also restrain myself from making this Drag-n-Drop for users
who may have a delicate stomach...

- Simplicity! A great deal of software can be built with very generic commands that
need only 40-60 lines of code. In the most simple case, only the name, version
and build-release number are changed, and maybe the suffix of the source code.
So for a case where you'd configure with './configure --prefix=/usr', the code is
reduced to just 7 lines. Example: tarball is named superprog-0.1.tar.bz2. The whole
script from tempdir creation to cleanup looks only needs this:

#/bin/bash
BUILD="1"
NAME="superpog"
VERSION="0.1"
SRC_SUFFIX=".tar.bz2"
source /usr/libexec/pkgbuild/FUNCTIONS
do_all_processes ;
exit 0


That's it! Even with such a simple template, many options and switches are available.
Only BUILD, NAME, VERSION and (sometimes) SRC_SUFFIX have to be changed to create
scripts for many, many packages. For anything that needs more detailed control, just
the fact that the script contains more code than this is makes it stand out at first
glance at the script.
And even complex packaging can be done with much less coding or 'translation' from other
packing builders scripts. One of my longest scripts, for gcc-2.95.3, actually build two
packages and still uses just 50-60 lines. A comparable Slackbuild for gcc takes about
250-300 lines of coding.

In the above script, 'do_all_processes' is just a shortcut way of running every step
of package building from start to finish. The Detailed.PkgBuild template runs the steps
individually. Steps can be canceled if not needed just by commenting one line. And code
can easily be inserted or variables set between steps, etc. The template format is
nearly as simple as above, but breaks the whole process into 16 steps. It's easiest to
show them and think of them as 3 groups:

# preparatory steps
pre_process ;
find_source ;
make_dirs ;
unpack_source ;
fix_source_perms ;

# the real nitty-gritty
configure_source ;
compile_source ;
fake_install ;

# make a sane package and wash dishes...
fix_pkg_perms ;
strip_bins ;
create_docs ;
compress_man_pages ;
make_description ;
make_doinst ;
make_package ;
post_process ;

Usually scripting changes are made or skipped in the middle, unless you are building
non-standard packages. But the exact order of execution of PkgBuild allows for nearly
every option and variable to be effectively controlled at most points.
The most-used variable names for scripting have been kept short for ease of typing.
PKG_DIR and SRC_DIR are usually all you need to know about. Still, some lesser-used
variables or options may do the opposite for better visiblity. The main configuration
and preference options which are seldom changed all have long self-explaining names
for easier understanding. Typically, few changes are needed to make PkgBuild do what
you want, while automating all the rest.

- Universal and non-standard Packages -PkgBuild includes several features for producing
specialized packages, such as filtering of locale files, compressing binaries or document
folders, etc. It can also easily be made to produce non-Slackware type packages.

- Humor -PkgBuild restrains itself when it knows it was you who made a mistake and
not some innocent developer's Makefile. The How, When and What of prompting is the
hardest thing to get right and flexible for users tastes. If you use QUIET=NO the
output from PkgBuild will be 'drowned-out' anyway by configure, make and make install.
Still, we are trying to make the output as useful and essential as possible for
easier interpretation -the same for the logs, database and dependency info.

I download the source and compile it. I would love to have some kind of script to automate the tasks though, a source based installer script, similar to portage that i've been enjoying in gentoo b4 i switched to slacky would make life much easier.
It need not have to take care of deps and so and so.
It just has to automate the tasks of ./configure --enable* --prefix=<dir> and make et al. We can specify what features to enable disable etc. Something similar.

That's exactly what Amigo PkgBuild does. If you grab the version 0.4 you'll have the framework to easily build and maintain hundreds of packages. I've just spent about 2 weeks on PkgBuild adding a lot of features. Try the existing stable one and watch for the new version which the above posting describes.
The stable-0.4 is pretty simple and does no error checking so you should check every package before installing it.

The default configuration does everything in the current directory, so it's very easy to try out. Just be sure you are root, create a directory somewhere and copy your favorite tarball there. Then grab one of the PkgBuild templates from the docs and copy to the same directory as the tarball. Open the PkgBuild script in your favorite editor and fill in the NAME, VERSION, BUILD and SRC_SUFFIX variables. Then save it as progname.PkgBuild. Then open an xterm there and type:
'./progname.PkgBuild'

To see the best case scenario, try it first with something that you know supports DESTDIR and will compile and install correctly when you give just this:
./configure --prefix=/usr
make
make install

If all sources would behave and didn't need more than that you'd never need more than 30 seconds to 'write' the scripts! But using the long version gives 100% control. The coming version goes much further and even processes non-standard, incomplete or defective sources. Plus it provides quite a bit of diagnostic info.