Have you ever reinstalled Slackware and spend a lot of time after this to install your favorite applications, compiling them one by one, or installing them from packages? Have you ever upgraded Slackware and ran into issues with the old programs that you had? This is a how-to guide for you.

Instead of compiling the programs one by one, or installing them manually, you can use one of the following methods:

Sbopkg
This is a little tool that is very handy after you re-install Slackware, and you want to get your favorite software back on the system. It uses a repository from SlackBuilds.
First, install sbopkg on your new Slackware installation:
(If this code installs an outdated version of sbopkg/or doesn't work, go to sbopkg website, click on the "Package" link on the top-right side of the page, and install the downloaded package with installpkg)
Then, open up the terminal (konsole in KDE), and login with root (type "su"). Then sync the repository.
Now you are ready to install all you need:
For example, if you want to install conky and dar, you type:
You can browse the packages available here: http://slackbuilds.org/repository/13.0/
If you want to browse the packages with sbopkg and use it's interface, just type:
when you finally make a list with all the packages you install every time, you make a list, with only the main names, separated by new line/interval, like this:
And save it in a sqf file. Then, with:
You can install the packages from your list. You can keep that list in your /home partition if you don't format it.

Pros:
+ The SlackBuilds.org repository gets updated very quick
+ You have a pretty wide catalog to chose from

Cons:
- It doesn't track the dependencies
- It takes a lot of time to compile the software


Slapt-get
Slapt-get is a pretty nice tool (if used right) to install software on your slackware system, from repositories with precompiled packages, with keeping track of the dependencies.
There are a lot of nice repositories for slapt-get, the most notable being Slacky.eu.

First, you have to install slapt-get. Go here, download the latest version, and install it with installpkg.
Then, you need to edit /etc/slapt-get/slapt-getrc:
And add the repositories you need (append "SOURCE=http://somewhere..." at the end of the file) and remove whatever you want. There are instructions inside the file.
Then type
To sync slapt-get with the repositories.
Then, you are ready to install whatever you want:
You can list the packages you can install with:
You may install gslapt (also from the same website). It's an graphical interface to slapt-get.

Pros:
+ dependency resolution
+ installs pre-compiled packages

Cons:
- there isn't a big variety of repositories


Src2pkg
This is a tool which compiles a package from source. No need for SlackBuilds, no need for nothing. Just the source, and compile it with this tool.
Installation of src2pkg is a little bit more complex than the others.
Install the package from here: http://distro.ibiblio.org/pub/linux/...nload/src2pkg/
Than run and follow the instructions.

After this, you are ready to use src2pkg. You can directly specify a link to a source package, src2pkg will download it for you automatically.
Here is an example:
This will download, compile, and install the conky package for you - automatically.
The process for every application is pretty straight-forward. You download it's source, and you use src2pkg to compile it, and automatically install it. Saves a lot of work.

Pros:
+ no need to rely on repositories, SlackBuilds, etc.
+ you can easily specify which version of a package you want to get

Cons:
- You need to manually update your links to sources



Methods for keeping track of dependencies
Ever wanted to share your packages with others, and include dependency information in them, so they can be handled well by slapt-get? Ever wanted to make your own repository? Here are some tools that find the dependencies of your packages.

Requiredbuilder
http://stabellini.net/requiredbuilder.html

Pros:
+ Can keep track of Python library dependencies and other script libraries
+ Has a lot of options

Cons:
- Very slow

Depfinder
http://freshmeat.net/projects/depfinder

Pros:
+ Very fast

Cons:
- doesn't keep track Python libraries, at least for now

WARNING
You can't use those tools to find the dependencies of a package, which dependencies are NOT met. All the dependencies of the package you are tracking the dependencies of MUST be met, or the dependencies that aren't met won't show in the package dependency list.



Recommended repositories with pre-compiled packages
Slacky.eu
This repository contains a lot of Slackware packages that doesn't replace a lot of the stock packages. It's definitely the richest repository with pre-compiled packages, and it also contains dependecy information. It even contains LXDE and Gnome.
Line in slapt-getrc:
Gnome SlackBuild
A repository containing Gnome and a lot of applications that come with Gnome/with the Gnome distributions. Also very rich. The problem with it is that replaces a lot of the stock Slackware packages, but if you don't mind it (I don't think it will cause a lot of stability issues) it's ok. It contains dependency information.
A line for slapt-getrc:
GWARE
A repository containing a really basic build of GNOME, again, it doesn't replace a lot of the stock packages. However, it contains only GNOME and GNOME applications (that is it's goal), and gets updated quite slowly. Also, it doesn't contain dependency information.
There isn't a version for Slackware 13.0 yet.

Alien's SlackBuilds
A SlackBuild repository, containing pre-compiled packages. With the Alien's activity in SlackBuilds.org, I don't think it will be seriously supported, but I don't know. It contains dependency information.
slapt-getrc line:
Salix repository
This is the repository of SalixOS, and it's compatible to Slackware.
What I noticed is that it has a lot of games, and it also has some parts of GNOME.
It has dependency information, and it's well maintained.
slapt-getrc line:



Take notice that this article isn't finish. I'm going to extend those instructions and add information about slackyd, slackpack. I will also add more info about how to make your own repository.

Thanks to:
> slakmagik for the suggestion for sbopkg queries.

Hope that helps.

Interesting writeup. I'd also mention sbopkg's queue feature. You can create a list of packages in a queuefile (even calling other queues recursively). The -i flag also accepts queuefiles as arguments. So you might rebuild and reinstall all your SBo packages with a simple 'sbopkg -i all_pkgs.sqf'.

Thanks. Version 2 of the article coming soon!

Hi Ivshti

Nice howto... :-)

One question... Immagine That I have built my system from scratch, installing only what I need... meaning... all the packages I built currently live in /tmp...

...now, If I want to deploy the same system in another machine... it is enough for me to burn some DVD(s) with everything that I installed, install Slackware w/ the same options, and use that DVD, #cd /mnt/dvd&&installpkg *.t?z and I am done...

is this correct...?

I will have my original system cloned, the order of the installation of the packages is immaterial... right...?!

BRGDS

Alex

Yes, of course. As long as a package has all it's requirements met (dependencies) it will run on a different installation.
If you install those packages on a clone installation, you can be 100% sure that they will run.


I'm almost sure that it's pretty easy to add the packages you have built to the Slackware installer and use it to directly install your customized system.
Burn Slackware 13.0 on a R/W disc, and tweak files.
Sorry, can't tell you (for now) which files exactly to tweak, I don't have DVD, I install Slackware without an installer (I download the packages with a ftp client and then install them with installpkg).



Just one tip:
Never use /tmp for packages. Assign some other, permanent place for your packages. /tmp is used, well, for temporary things and it's best (if you have enough RAM) to mount it with tmpfs, and you will get much faster system, since /tmp will be stored in your RAM, and you will also be able to limit it, because it's very annoying to have your / jammed because of uncleaned /tmp. It will be also cleaned on reboot.

I always keep copies of updates and compiled packages in my /home/samac/packages directory and its sub-directories. I never re-format /home as it is on a separate partition so all I need to do if I have to re-install is as root, and my system is completely replaced as it was.

samac

There is a really nice "extension" for slapt-get available from the guys of Salix. They offer not only a well managed repo with a lot of nice-to-have-apps 100% compatible to slackware13, they give you also a way to create a local repo of slackware13 with dependency support. So if you'll have to install something from the original slackware repo, it's really a cinch to do this via slapt-get.

It's explained very well here: http://www.salixos.org/wiki/index.ph...ndency_support

Ivshti,
Very good tutorial. I have been using sbopkg to manage all my slackbuilds from slackbuilds.org and it has always worked well for me.
You may want to add Slackpack Package Manager from MysticalGroovy to your list:
http://www.linuxquestions.org/questi...anager-758501/
http://slackpackpkgman.wordpress.com/
I have not used it, but it does seem to fill a niche that the other 3rd party Slackware package tools do not.

Thank you all. Hopefully I will add information about dependency trackers today.
There are a few methods for that, all using ldd.
Famous ones are requiredbuilder and depfinder.

Also, I will add information about how to maintain your own repository. The current methods I know are, Alien BOB's script, the script from software.jaos.org, and the Salix method.


BTW anyone interested in repository of all the SBO packages precompiled? I think I'll have the time to maintain it, at least for x86 arch.

If you do make such a repository available to the public, we (slackbuilds.org admins) kindly ask you to change the "SBo" tag in your packages to something else. We do not want to be associated with a 3rd party package repository - all we will vouch for are the SlackBuild scripts (which is why we always make the GPG ".asc" file available that allows you to check that you are actually using the script that was approved by a slackbuilds.org admin).

There is no way we can guarantee that a package containing the "SBo" tag was created using an unmodified SBo script.

Eric

No problem.

Any one who likes the idea? I don't think there is a point of doing this, because Slacky.eu exists. If I make that repository, it will contain only packages that aren't in Slacky but are in SlackBuilds.org.
Like Openoffice.org, Supertux, etc.

Hi Ivshti

Would be a nice idea... :-)

I mean.. compiling stuf like OpenCascade, or OpenOffice from source is a bit of an adventure... :-)

... Furthermore... most ( more like all ) of the precomps in Slacky.eu are 32 bits...

Pure 64 bit users like me compile stuff from source...

BRGDS

Alex

Repository list added. I'll also add alternative slapt-getrc lines for 64 bit machines.

And BTW, I agree. OpenOffice package is a must. I once wrote to rworkman to do a minor modification to his SlackBuild that allows easier addition of OpenOffice extensions to the package. That will come pretty handy now.

Also, look at the slackyd description when I add it. It will come pretty handy if you want to manually compile 64 bit packages.