Info
slapt-get is an APT like system for Slackware package management
Source
Features
slapt-get tries to emulate Debian's apt-get as closely as possible.
-
uses native Slackware tools (installpkg, upgradepkg, and removepkg)
-
supports multiple package sources (including linuxpackages.net)
-
cache data concerning packages and updates from package sources
-
supports sources from ftp, ftps, http, https, file:/// and more (libcurl)
-
resumes broken downloads and will verify package integrity with MD5
checksum
-
show packages that are available (from cached data) and installed
-
search package listing using POSIX and extended regular expressions
by package name, location, and description
-
retrieve, install, and remove packages by name or by specific version
-
retrieve and apply updates
-
upgrade from one Slackware release to another in a few simple steps
-
show description of packages, including mirror location, version, size,
dependencies (where available), conflicts (where available), suggestions
(where available), description, installation status, and the package
changelog entry (where available).
-
exclude (hold) packages from upgrades, by name or by regular expression
-
transaction engine for install, remove, and upgrades, reporting concise
information on what is to be done, ensuring each step happens correctly
-
"compare package version" algorithm to prevent downgrades
-
recursive dependency resolution using slack-required meta-data (see FAQ)
supporting hard, soft, and conditional dependencies
-
package conflict resolution using slack-conflicts meta-data (see FAQ)
-
package suggestion support for complimentary packages (see FAQ)
-
Package data download robustness, only writing changes if all sources
download successfully as well as only downloading those sources that
have changed since the last download
-
i18n support via GNU gettext with over 24 language translations
-
extremely fast and easy to script with
Help
Quick Help
$ slapt-get --help
slapt-get - Jason Woodward <woodwardj at jaos dot org>
An implementation of the Debian APT system to Slackware
Usage:
slapt-get [option(s)] [target]
Targets:
--update - retrieves pkg data from MIRROR
--upgrade - upgrade installed pkgs
--dist-upgrade - upgrade to newer release
--install [pkg name(s)] - install specified pkg(s)
--remove [pkg name(s)] - remove specified pkg(s)
--show [pkg name] - show pkg description
--search [expression] - search available pkgs
--list - list available pkgs
--installed - list installed pkgs
--clean - purge cached pkgs
--version - print version and license info
Options:
--download-only - only download pkg on install/upgrade
--simulate - show pkgs to be installed/upgraded
--no-prompt - do not prompt during install/upgrade
--reinstall - re-install the pkg
--ignore-excludes - install/upgrade excludes
--no-md5 - do not perform md5 check sum
--no-dep - ignore dependency failures
--disable-dep-check - skip dependency check
useful slapt-get commands
Please refer to the documentation for slapt-get: man slapt-get, the HOWTOs
at the VL Forum: slapt-get basics and gslapt basics or go to the slapt-get
FAQ site for more advanced topics.
You may wish to try some of these slapt-get commands:
-
to list all the available packages from the source repository:
-
to list only those packages that you have already installed:
-
to search the listings for specific package(s):
slapt-get --search [packagename(s)]
-
to install (or to upgrade an already installed) package(s):
slapt-get --install [packagename(s)]
-
to remove packages(s):
slapt-get --remove [packagename(s)]
-
to clear your temp directory of downloaded packages:
-
to show a package(s) description:
slapt-get --show [package(s)]
-
to reinstall an existing package:
slapt-get --reinstall --install [package]
-
to downgrade a package:
slapt-get --reinstall --install [exactpackagenameandnumbers]
-
to show a sorted, paged list of available packages from the source repository:
slapt-get —available | sort | less
-
to show a sorted, paged list of installed packages on your system:
slapt-get --installed|sort|less
-
to show a sorted, paged list of available, uninstalled packages:
slapt-get --available|grep inst=no|sort|less
-
to show only available packages related to e.g. fluxbox:
slapt-get --available|grep fluxbox
-
to show only available, uninstalled packages specifically packaged for VL5:
slapt-get --available|grep inst=no|grep vl5|sort|less
-
to install all packages pertaining to e.g. fluxbox:
slapt-get --available|grep fluxbox|awk '{print $1}'|sort|uniq|xargs -r slapt-get --install
-
to install every available package not yet installed (DANGER!):
slapt-get --available|grep inst=no|awk '{print $1}'|sort|uniq|xargs -r slapt-get --install
Slackware Packages
VectorLinux is able to install Slackware packages. However, Slackware does
not normally support slapt-get nor do Slackware packages do any dependancy
checking. For this reason we do not recommend enabling any Slackware
repositories in the /etc/slapt-get/slapt-getrc configuration file (or with
gslapt, Edit, Preferences, Sources, Add a Source). The default slapt-get
configuration file will enable the user to download and install Vector
packages only. Slackware packages which are non-system packages will
probably work fine with VL but you may have to install all the dependant
packages first and there is no guarantee the package will work properly. If
you do decide to load a Slackware package please ensure you download
packages built for the correct version of Slackware.
I get the following error when using slapt-get
Sources failed to download, correct sources and rerun --update
Seems that it is because of the failure verifying the checksum signature:
$ slapt-get -c slapt-getrc.slacky --update
Retrieving package data [http://slacky.uglyplace.org/repository/slackware-12.1/]...Cached
Retrieving patch list [http://slacky.uglyplace.org/repository/slackware-12.1/]...Done
Retrieving checksum list [http://slacky.uglyplace.org/repository/slackware-12.1/]...Cached
Retrieving checksum signature [http://slacky.uglyplace.org/repository/slackware-12.1/]...Cached
Verifying checksum signature [http://slacky.uglyplace.org/repository/slackware-12.1/]...Not Verified
Sources failed to download, correct sources and rerun --update
My distro don't have the slapt-get man page installed, and I can't find the slapt-get man page on web. So I don't know how to fix it. Please help.
PS. trying to add the '—no-md5' to the command line doesn't help.
slapt-get: Verifying checksum signature failed
-
Did you remember to run 'slapt-get —add-keys' after adding the new source?
-
Are you using the latest slapt-get version? Should be 0.9.12d
-
Are you able to access the repository from your browser?
Just for reference here is my file:
# See /usr/doc/slapt-get-0.9.12d/example.slapt-getrc
# for example source entries and configuration hints.
WORKINGDIR=/var/slapt-get
EXCLUDE=^kernel-.*,^alsa-.*,^glibc.*,.*-[0-9]+dl$,^devs$,^udev$,aaa_elflibs,x86_64
SOURCE=http://slackware.mirrors.tds.net/pub/slackware/slackware-12.1/[]
SOURCE=http://slacky.uglyplace.org/repository/slackware-12.1/[]
SOURCE=http://software.jaos.org/slackpacks/12.1/[]
documented on: 2008-06-26, digger95
slapt-get: Verifying checksum signature failed
> 1. Did you remember to run 'slapt-get --add-keys' after adding the new source?
That IS the reason. Problem solved. Thanks, Dig.
% slapt-get -c slapt-getrc.slacky --add-keys
Retrieving GPG key [http://slacky.uglyplace.org/repository/slackware-12.1/]...Cached
GPG key successfully imported.
% slapt-get -c slapt-getrc.slacky --update
Retrieving package data [http://slacky.uglyplace.org/repository/slackware-12.1/]...Done
Retrieving patch list [http://slacky.uglyplace.org/repository/slackware-12.1/]...Done
Retrieving checksum list [http://slacky.uglyplace.org/repository/slackware-12.1/]...Done
Retrieving checksum signature [http://slacky.uglyplace.org/repository/slackware-12.1/]...Done
Verifying checksum signature [http://slacky.uglyplace.org/repository/slackware-12.1/]...Verified
Retrieving ChangeLog.txt [http://slacky.uglyplace.org/repository/slackware-12.1/]...Done
Reading Package Lists...Done
documented on: 2008-06-26, xpt
I was wondering if the more experienced members would not mind sharing the
way that they handle/manage packages on their system. Obviously when a
Slackware package is available, using installpkg is the logical choice. I
also use slapt-get to keep my system up to date with the latest security
patches. . .
It'd be nice to have everything in a centralized place so I can just use
pkgtool to manage everything. Should I just learn to write SlackBuilds
scripts, or are there other alternatives?
Slackware Package Management Best Practices
-
Most packages can be managed using tools like slackpkg/slaptget/swaret
(which are scripts around the standard Slackware pkgtool suite). These are
usually set up to communicate directly to a Slackware mirror. I use
slackpkg.
-
For software that doesn't come from an official Slackware package
repository, but has a package, I'll download it and manually use
installpkg. For me, this includes stuff like the proprietary ATI drivers
or stuff from linuxpackages.net.
-
For software that comes as a binary package, but not in Slackware tgz
format, like rpms, I'll use src2pkg.
-
For software that comes as source code, I'll either use src2pkg or a
SlackBuild. In the old days, I would configure, compile, and at the make
install step run checkinstall to create a Slackware package (then I use
installpkg). These days I've found src2pkg to be really good.
Hope this helps. Looks like the only thing you are really missing is src2pkg or trackinstall/checkinstall.
Last edited by jelaiwang : 04-16-08
Slackware Package Management Best Practices
> > if you have already compiled your software you can create the package
> > directly with "trackinstall" (comes with src2pkg). You don't need to
> > re-compile it by running src2pkg.
>
> I remember gnashley saying somewhere that people should use src2pkg and not
> trackinstall as src2pkg does more stuff
there are several good reasons to use src2pkg instead of
trackinstall. Mainly because it will keep a better record of any special
options you have passed to the configure script, but it is also very helpful
when the sources can't be configured and compiled with the usual
'./configure && make && make install' trio of commands. It is also able to
handle sources that use scons, jam, imake and cmake -usually without any
help at all. There are only a couple of cases where trackinstall may be able
to create a package and src2pkg can't -such as with some pre-compiled
binaries which use an interactive installation script.
I'm glad to see that jelaiwang mentioned using src2pkg instead of rpm2tgz —
src2pkg does a much more thorough job of converting binary packages from rpm
or deb format since the resulting package conetent id subjected to all the
usual src2pkg conetent checks — like being sure that directories have the
right ownership and permissions, plus stripping the libs and bins,
compressing the man-pages if needed and any other special steps which you
ask for. rpm2tgz has been around a long time and is part of the official
Slackware release, but it is really not adequate for converting *binary* rpm
packages, though it works fine for converting srpm's — that is rpm source
archives. If you point src2pkg at an rpm source archive, it will unpack it
and try to compile it like a regular tar.gz/tar.bz2 source archive.
My advice about keeping your system up-to-date is to just check the
Slackware site from time to time for patches to your installed version, or
subscribe to receive the security upgrade notices. Then just manually
download the packages and use upgradepkg to install them. Trying to keep up
with 'current' is not a good idea if you like to keep your installation
stable or if you have other things to do besides continually messing with
your system.
documented on: 04-17-08, gnashley
When I was using Redhat, I found that many tools that I wanted did not come from the official repository. Rpmfind was the top site that I visited, but even so, I sometimes experiences difficulties installing packages, because,
-
sometimes the rpm packages cannot be found
-
even when it can be found, it might not be for the right version of Redhat
-
that seems to be the most annoying thing to me — the version available to Redhat was old, the latest version of the tools that I was looking for was only available from some "alien" systems that they could not be installed into my Redhat because of the lib version mismatches.
-
the worst case was that I had to build the packages myself. It was true PITA to solved the "dependency hells".
After I switched to Debian, the package installation hassle was over. I never ever had any problem installing the tools that I want under Debian. Housing cleaning, i.e. removing unwanted tools, is easy as well.
-
its official package repository is even smaller than Redhat.
-
"In most cases, manual compilation of many packages will be needed".
-
Slackware's (official) package manager does not have the ability to resolve dependencies, because Slackware's creator Patrick Volkerding indicates that not everybody thinks highly about advanced package management tools: "I'm not a big believer in automated dependency handling."
If you want to find the easy you have in Debian from Slackware, you have to find very hard since the dependency handling is not officially supported or even encouraged. Luckily, there are unofficial tools, but, which one to choose? Many people prefer slapt-get in the Slax community, fewer talk or even know about swaret, but the reality is,
-
slapt-get doesn't do dependency check for official packages whereas swaret does.
-
swaret and slackpkg are officially included in the "extra" directory of Slackware Linux, whereas slapt-get is not.
That brings more complexity to choosing the dependency handling tools. And since the official package repository is so small, you have to rely on some unofficial ones if you want better luck to find the packages for the tools you are looking for. slapt-get FAQ suggests 3: linuxpackages.net, CollegeLinux and VectorLinux. Among them and others, which one is better?
The conclusion is base on the following collected articles.
documented on: 2008-05-17
slapt-get & package dependencies
First of all, slapt-get does not provide dependency resolution for vanilla
Slackware packages (ie, official Slackware packages that come with the
distribution).
However, slapt-get does provide a framework for dependency resolution for
packages that follow the Slackware package format, while still being
backwards compatible. This information is stored in so called meta files
within the package.
Packages supporting this framework can be found at linuxpackages.net, along
with several Slackware derived distributions such as CollegeLinux (starting
with 2.5) and VectorLinux (starting with 5.0).
Also, Stefano Stabellini has created a PACKAGES.TXT that contains the
dependency information for Slackware packages without modifying the actual
packages themselves. This can be used as a slapt-get source to pull the
packages from official slackware.com mirrors. Read more about it at
Stefano's page: http://www.stabellini.net/depslack.html
Slackware Linux
September 24, 2003
contributed by Ladislav Bodnar
Slackware's package manager does not have the ability to resolve
dependencies. The MPlayer experiment started with a trip to LinuxPackages,
where I located and downloaded the necessary package, then executed
installpkg:
installpkg mplayer-1.0pre1-i686-2rob.tgz
Although no errors were reported during installation, MPlayer failed to
launch due to missing libraries. Back to LinuxPackages to download alsa-lib,
lame and libdvdread (the dependent packages were clearly listed on the
MPlayer download page), before installing them with installpkg. This has
satisfied all requirements and MPlayer was ready for action.
There are three third-party packages that handle Slackware package updates -
these are swaret, slackpkg and slapt-get. Both swaret and slackpkg have now
been officially included in the "extra" directory of Slackware Linux, but
between the two of them only swaret has the ability to resolve dependencies,
while slackpkg is generally used to keep a Slackware system synchronized
with the "current" branch (i.e. development branch, equivalent to Sid,
Cooker or Rawhide). At this point, it is perhaps interesting to note a
recent comment by Slackware's creator Patrick Volkerding, which indicates
that not everybody thinks highly about advanced package management tools:
"I'm not a big believer in automated dependency handling."
As with all other distributions in this experiment, I wanted to upgrade a
vanilla Slackware 9.0 installation to the latest available development
version, which at the time of writing was Slackware Linux 9.1-beta2. This
can be done with Slackware's native tools, but the process is fairly
involved, it requires manual download of all upgraded packages, which then
need to be upgraded with upgradepkg in a certain correct order. After
downloading and installing swaret, the same could be achieved with two
commands:
swaret --update
swaret --upgrade -a
Again, the process took time, but completed with no errors. Several newly
upgraded packages required extra packages to satisfy dependencies and this
is the only place where user intervention was called for to confirm the
action. But the overall experience was very similar to upgrading Mandrake,
except that it required a third-party tool.
Overall score (2 points were deducted for having to use a third-party
package manager): third-party package installation: 5, distribution upgrade:
7.
|
the article not only covers Slackware, but also all major distros. |
Conclusion
To conclude this lengthy and time consuming experiment involving package
installations and distribution upgrades, we have two clear winners - Debian
and Mandrake. Debian is hard to beat when it comes to overall convenience,
but Mandrake has made a lot of effort and its urpmi package management and
underlying technology has just about succeeded in catching up with
Debian's. The other three distributions have a long way to go. Red Hat is
currently in a major transition and the question of package and distribution
upgrades is probably being addressed as I write this. Slackware is easy to
upgrade with swaret, a tool which will be included in the upcoming Slackware
9.1, but it doesn't handle installing packages from third-party
repositories. As for SuSE, it falls short of all other distributions. YOU
has a pleasant interface and it works extremely well within its official
package set, but as a software management tool, it has too many shortcomings
to compare well with either apt-get or urpmi.
Swaret and slapt-get from my point of view
by: Anonymous Coward on October 20, 2006 04:06 AM
I have used both Swaret and slapt-get to automate downloading and installing
Slackware packages. I don't think any of them is specially good, but I use
slapt-get as the "less bad" of the two. I'll highlight the good and bad
points of each tool, from my point of view. Also, take into account this
information belongs to the stable swaret release. I think a new version is
being worked on, and it's in Perl IIRC.
[Good] Checks GPG signatures instead of MD5 checksums.
[Good] Checks binary dependencies without using any additional information. This is quite useful.
[Good] As easy to use as slapt-get.
[Bad] It's a shell script. Very big. Very, very slow. slapt-get uses much, much less CPU.
[Bad] I didn't find a way, and let me know if there's one because I truly tried to find it, of automatically downloading and installing patches for the installed packages. You can either answer manually or install all of them, including the ones belonging to previously not installed packages.
[Good] Written in C and it's much faster.
[Good] It has the patch behaviour I commented previously, that swaret seems to lack.
[Good] Keeps directory hierarchy in downloaded packages.
[Good] Has the option of removing local packages not present in the remote side (good for people using -current, to clean the package tree from time to time).
[Bad] Doesn't detect binary dependencies.
[Bad] Doesn't check GPG signatures.
[Bad] I don't like the output format. It's similar to the one from apt-get. Swaret's output format isn't beautiful either, but I like it better.
|
|
the article is wirtten in year 2006. Now Swaret is written in Perl. So the first [bad] does not hold any more. and the second [bad] is controversial even by then. |
Swaret and slapt-get from my point of view
You must have been doing some thing wrong. Swaret has never defaulted to
functionlike that in my experince. IT has always only upgrade installed
packages only. Just run swaret —upgrade -a to upgrade all installed
packages. It does not install any non-installed packages.
Swaret and slapt-get from my point of view
It all really depends on whether you set the VERSION to the version you are
running or current.
Current doesn't have any patches; they just become the new package. By
setting the version to 11.0 (or whatever version is installed) and using the
upgrade command, it looks at what packages you have installed (by
referencing the<nobr> <wbr></nobr>/var/log/packages directory) and downloads
available patches for installed apps.
Swaret and slapt-get from my point of view
> [Bad] Doesn't detect binary dependencies.
Slapt-get can actually check for dependencies if a file called
slack-required is in the install directory of the package. It can also
resolve dependency conflicts based on the contents of
slack-conflicts. "Official" Slackware packages do not include either of
those files in the package. That's why there is no dependency checking for
"official" Slackware packages.
With that said, however, slapt-get WILL check for dependencies in packages
made by some Slack derivative distros like VectorLinux. It will also check
for dependencies in packages distributed through linuxpackages.net.
by: Administrator on October 21, 2006
Compare distros, Debian vs Slackware
Small number of official (vanilla) packages. In most cases, manual
compilation of many packages will be needed. Sometimes there is an
alternative being unofficial Slackware packages downloadable from project's
pages or LinuxPackages and Slacky.it.
Slackware's package management system is based on the simple tgz packages
which do not contain any information about dependencies. Additional
unofficial packages can be found on LinuxPackages and Slacky.it. These
packages are in extended tgz format — so that they can contain
meta-information about dependencies (but unfortunately in each case). There
are two programs that can use this information: swaret and slapt-get
(together with graphical frontend GSlapt). Many additional tools has been
designed to improve Slackware package management — from tiny scripts to
full systemy portow (Emerde, pkgsrc, Portpkg). It is also possible to create
own packages using checkinstall utility.
Obtaining And Adding Software
The easiest way to obtain software for your custom Slackware distro is using
a site called Linux Packages. Linux Packages has a wealth of slackpacks,
submitted by several members of the Slackware community.
By Mayank Sharma on February 20, 2007
Slackware Linux is the oldest surviving Linux distribution. Late last year
the project marked 13 years of non-stop development with the release of
Slackware 11.0. The distribution is best known for its no-frills, minimum
customizations approach to applications like KDE. It's also notorious for
its reluctance to switch to new version of several popular applications like
Apache or GCC. No surprise then, that its package management system has seen
little change over the years and is still available in just one flavor —
vanilla.
A Slackware package is a simple gzipped tarball of the form
name-version-architecture-revision.tgz, for example,
php-5.1.6-i486-2.tgz. When you uncompress and extract the contents of this
tarball with tar -xvf php-5.1.6-i486-2.tgz, you get three directories, etc,
usr, and install. The install directory contains a do-inst.sh script that,
in essence, helps Slackware assimilate the contents of the unzipped etc and
usr directory into the /etc and /usr directories under the root directory.
Installation on Slackware might sound plain and simple, but it really
isn't. Sure installing stand-alone applications isn't an issue. But when it
comes to installing applications that depend on other programs and
libraries, the Slackware package management tools fall flat on their face.
Unlike packages made for repository based solutions, like Debian's apt-get
and Fedora's yum, Slackware packages were not designed to be
dependency-aware — and hardcore Slackware users would have it no other
way. Installing dependencies by hand does have an advantage. It allows an
administrator to remain in control of the libraries and programs installed
on the system.
But being one of the oldest distributions has its advantages. Thanks to its
faithful bunch of developers, Slackware has perhaps the largest collection
of package management tools. Let's look at some of them.
Slackware has a bunch of packaging tools that are as old as the distribution
they support. Up front is the pkgtool utility that brings up a ncurses menu
driven interface. With this tool you can install packages from the current
directory or from another one. The tool is also aware of all the installed
applications and can be used to remove several at one go. You can also view
an application's brief description and a complete list of files contained
within any installed application.
Apart from pkgtool, Slackware has tools that will help you install, remove,
and upgrade packages. The installpkg, removepkg, and upgradepkg utilities
all take the name of an application as an argument and install, remove, or
upgrade them, respectively.
You can also use the -warn option with the installpkg and removepkg
commands. Instead of installing an application, this switch will simply
print a list of files and directories that would be overwritten or removed
if you install a particular package.
Want to know what a package will install before you pull the trigger? Use
the explodepkg command to uncompress the tarball into the current directory
and view its contents.
Installing non-slackware packages
Despite Slackware's longevity, many application developers don't supply a
Slackware package. In that case you have two options, either build the
application from source or use its RPM package if it's available. To make
use of an RPM package it has to be first converted into Slackware's package
format. This can be done using the rpm2targz and rpm2tgz tools. I
successfully converted RPMs of several simple applications like that of Joe
Text Editor, into tgz and installed and removed them without any issues.
If you decide to install from the source, you should do so through the
CheckInstall tool, which itself is available as an easily installable
Slackware package. Installing an application from source involves running
the ./configure, make and make install commands that configures, compiles,
and installs the application.
CheckInstall kicks in just before make install and learns everything the new
application will add to the system. It then simply creates the Slackware
package. We've written about CheckInstall in our CLI Magic series.
The biggest drawback of Slackware's pkgtool is that it can only install
packages available locally on the machine. This is where the Slackpkg tool
comes into play. Slackpkg is designed for installing or upgrading packages
through network. It works on the principles of online repositories, much
like Debian's APT. The tool gets package information from one of the
official Slackware mirrors. You can use this information to search for
packages and automatically download and install them.
Slackpkg isn't installed by default, but is available in the extras/
directory on the second Slackware installation CD-ROM and can be easily
installed using installpkg. Before the tool can be used, you need to edit
the /etc/slackpkg/mirrors file and select one mirror by uncommenting its
corresponding location.
After selecting the mirror, the slackpkg update command will download some
important files from the mirrors, like the GPG key, which will help verify
the authenticity of the packages. Once the tool has updated itself, it can
be used to manage packages. Once a package has been retrieved from the
online repository, in the background, Slackpkg uses Slackware's installpkg
to install them, along with the removepkg and upgradepkg tools to remove
packages and install updates.
The tool puts Slackware on par with other modern distributions that can be
completely installed and updated over the network. But it still has some
rough edges. As we've mentioned in our Slackware 11.0 review, the tool's
search feature can sometimes return strange results.
All the tools that we've covered until now are incapable of resolving
dependencies. This is a big turnoff for many desktop users. Just blaming the
tools wouldn't be appropriate. Like I've said earlier Slackware's package
format itself isn't designed to be dependency aware. This led several
Slackware users to design a new format, called the Extended TGZ. Packages in
the extended TGZ format contain information about the package's
dependencies.
Third-party Slackware packages, aware of dependencies, are maintained at
LinuxPackages.net and Slacky.it. These resources have active communities and
between them, you'll find the latest versions of most of the applications
you need.
But the packages themselves can't resolve dependencies, and neither can
Slackware's pkgtool or slackpkg. This paves the way for the Swaret and
Slapt-get tools.
Swaret is probably the most popular Slackware package management
application. Like Slackpkg, it's designed to install, upgrade packages over
the Internet and it can grab packages from the official
repository. Furthermore, with swaret you can grab packages in third-party
repositories like LinuxPackages.net. Swaret is also capable of installing
missing libraries that an application depends upon.
After grabbing and installing swaret's TGZ, rename its sample configuration
file to /etc/swaret.conf and edit to select mirrors and other options, like
its local tgz store. Unlike upgrades with the upgradepkg tool, swaret can
backup a package that its upgrading and can rollback to this older
version. You can script swaret to automatically update your Slackware
distribution when a new version is released.
But if you want true dependency resolution, there's no better tool than
slapt-get. It works with multiple repositories and can resolve both
libraries and application dependencies. I prefer slapt-get to swaret, since
it has all of swaret's features, and its options are very similar to
apt-get, and is scriptable too. Like slackpkg, slapt-get uses Slackware's
native package management tools, installpkg, removepkg, and upgradepkg for
managing packages. Slapt-get also has lots of usage-related documentation.
Portage for Slackware
The Gentoo Linux distribution is best known for its Portage package
management system. Portage is a collection of build scripts that is used by
Gentoo's emerge utility to configure, compile and install a package. The
system also provides for dependency resolution. If you'd like to have a
system like Portage on Slackware, there are two options: Emerde and Portpkg.
Emerde syncs with Gentoo's Portage tree, downloads the necessary build
scripts, and installs them on Slackware. Emerde is still in beta and its
developers advise installing it on a minimalistic Slackware installation to
avoid possible conflicts with packages. The application can also be used to
install Slackware packages directly.
Another approach to bring portage-like functionality to Slackware is
Portpkg. Instead of using Gentoo's portage, Portpkg uses Slackware's own
build file, SlackBuild. Portpkg has been built from the ground up to custom
fit Slackware and can be used along-side swaret and slapt-get to keep the
system updated, without causing any package conflicts.
Between the two systems, Portpkg is the more comfortable one for new users
since its similar in usage to Slackware's installpkg tool. Since Emerde
syncs with the online repositories, it's not a viable option for users with
slow Internet connections. On the other hand, don't expect Portpkg to have
build files for every application out there.
Conclusion
Slackware is designed for users who prefer to be in complete control of
their system. They swear by Slackware's package management system and will
have it no other way. However, another other group of users, spoiled by the
one-click installation systems of newer distributions, fail to understand
Slackware's lack of dependency resolution.
documented on: 2008-05-17
It seems to me that linuxpackages.net is the most popular third-party
repository. And my question is how to use it with slapt-get?
But when it comes to practice, I have the following questions.
-
Does linuxpackages.net contains official packages as well?
-
If not, do you recommend VectorLinux's repository? Does it have more packages than linuxpackages.net?
-
Will setting above find all packages from linuxpackages.net for me? Or it is only for the very version of Slackware that I choose?
-
If I can't find the package that I want in Slackware-12.1, will packages from Slackware-12.0 be OK for me?
-
If it is OK, how can I make slapt-get search Slackware-12.1 by default then fall back to Slackware-12.0 when not found?
-
more on package finding, while doing random checking of the available packages, the first two packages from http://www.linuxpackages.net/packages.php, FFmpeg & Firebird, I don't see them in http://www2.linuxpackages.net/packag…1/PACKAGES.TXT
In this case, would slapt-get search find those 2 packages for me?
If not, what should I do?
All in all, what's the best practice using third-party repositories?
Third-party Repositories
slacky.eu is a more reliable source than linuxpackages.net in my opinion. I
know nothing about slapt-get or slackpkg, so I can't be more help than that
— I will just say that linuxpackages.net has some poorly-built packages
with questionable dependencies that have the possibility to bork your
system. Although there ARE some reputable packagers at linuxpackages.net,
you would have to find out which ones are reputable and only use their
packages — and that's a lot of work, and not very convenient when using
slapt-get. slacky.eu has a large repository with well-built packages that
all include a SlackBuild so you can see how they built it or compile it
yourself using their SlackBuild, if you want.
I trust slackbuilds.org, Alien Bob's repository
(http://www.slackware.com/~alien/slackbuilds/) and rworkman's repository
(http://rlworkman.net/pkgs/) 100%, and slacky.eu 50% (though I'm a pessimist
and I always just use the SlackBuilds from slacky.eu and not their pre-built
packages). If you want huge repositories with every package you could
possibly want, Slackware isn't the distro for you — some packages won't be
available anywhere and will need to be compiled (by you) from source. That
being said, with the nice repositories listed above, that would be an
exception instead of a rule, but just be warned.
documented on: 2008-05-18, T3slider
Third-party Repositories
The only ready made packages that I will use is rworkman's, Alien Bob's, &
sometimes slacky.eu.
documented on: 2008-05-19, slackass
Third-party Repositories
-
. .I have also in the past downloaded from linuxpackages.net but only from
one particular packager who consistently does good work. Never had a problem
with his packages. . .
May I know who the packager is? Who else do you think might be good as well?
2nd, do you download from web or you use slap-get to download the package and all its dependencies? If so, how do you do that?
Third-party Repositories
I no longer use linuxpackages.net to be honest. I primarily use slackbuilds,
src2pkg, or download ready-built packages from the official repo, alien bob
or rworkman. However that's not what you're asking, so…
If you want to download packages and get dependency resolution as well, I
would trust slacky.eu only. They build good packages and their dependencies
(so far) seem on target. Nothing has downloaded and installed to my machine
that made me scratch my head anyway. You can use either one of the following
with slapt-get/gslapt:
Before I started using slapt-get though I learned to do my own packaging and
dependency handling, so I already have a good idea what should or shouldn't
be downloading to my machine, and I also compare what's going to be
downloaded with what's already in /var/log/packages to make sure nothing
gets overwritten.
I gave several options and i think it already represents the most common way
to install non official packages
You can choose more than one answers for this poll
How Do You Install Non Officials Packages
In just a day, the vote has got a huge response from Slackware users around
the world. So far, 72 peoples have vote for it and most of them voted for
Slacky.eu. It seems that including Slacky.eu is the correct decision as it
has so many users worldwide. I still believe there are still a lot of users
out there. So please came by and vote for it.
How Do You Install Non Officials Packages
Thanks to everybody who contributes to this votes as it claimed as the
highest record on my blog (184 voters). The question was "How Do You Install
Non Officials Packages?" and the results are as follow:
-
Get from Slacky.eu (107 - 58%)
-
Compiled it from source (74 - 40%)
-
Using SlackBuilds (52 - 27%)
-
Get from LinuxPackages.Net (46 - 25%)
-
Get from other Repository (10 - 5%)
-
Convert from RPM/DEB (17 - 9%)
All of my options are voted, but as usual, we always have a winner, so this
month poll's winner is the third option, Get from Slacky.eu.
FYI, Slacky.eu is an Italian Slackware community that has wide community (if
you are looking at the poll results above, you will see what i mean) and
it's not coming just from Italian people. They gave SlackBuilds script to
compile the source code and turn it into tgz packages which is the native
Slackware format so that you can easily manage them using
installpkg/upgradepkg/removepkg commands. Although the website is build
using Italian language, most of the package name are still reserved in
English, so i guess you won't find it hard to find the packages you are
looking for.
I know that the options listed here are not the only ways of installing a
package in Slackware Linux, but i guess it can accommodate the most common
ways to install third party packages.
documented on: 2008-05-19
The question is What is Your Favorite Package Management? and i gave 6
options, but at the end, only 4 who was voted by the audience and here's the
results:
-
Pkgtool 45 (42%)
-
Slapt-Get 29 (27%)
-
Slackpkg 20 (18%)
-
Swaret 12 (11%)
-
SlackMan 0 (0%)
-
GetPKG 0 (0%)
The winner is Pkgtool with 42%, the default Slackware package manager
tool. It seems that people still like the default application, even though
it's lacking of automatic download, automatic dependency solver, and many
more compared to automatic tools such as Swaret and Slapt-Get.
The runner up is Slapt-Get, with 27%. Even though it's not an official
package in Slackware, people seems to like this tools, as it can
automatically download the updates and install it for you. Even so, it's
best to use this tool for -Stable release only. DO NOT use this kind of
tools when you are playing with -Current and you KNOW what you are doing
with it. I have seen many people screwing their system just because they use
automatic tools like this and misconfigured them.
documented on: 2008-05-19
I noted in my entry yesterday that I'm thinking of doing a low resource
slackbuild. Part of the reason for that is my experience with both Slackware
and Vector Linux. Not to mention my experiences with Damn Small Linux in
both traditional and frugal installs.
Now that I've had a few months to use Vector, I've found several things that
cause me second thought about recommending it. I'll check the Vector forums
later today to see if these are issues others have dealt with. Last time I
went to the Vector site, it had been hacked (search my vectorlinux category
for screenshots).
(Edit noon CDT: I've been to the Vector forums and I'm awaiting approval to
post in their forums.)
First, upgrade options in gslapt have been disabled. This means users are
unable to upgrade their systems using the default package management
system's GUI. I haven't found out yet if it's still possible via slapt-get
or other parts of pkgtools. I can't blame Vector for conflicts due to using
different repositories, but Slackware and slacky.eu repositories are NOT
suitable across the board for use in Vector. I found this out when trying to
update OpenSSH and getting an error from SSL not matching the version
against which SSH was compiled. Easy fix to revert to the older version. I
still haven't found the security update for OpenSSH in Vector's
repositories, though. Which is the underlying issue for me — security and
upgrade-ability.
Second, the base packages are very bloated. I appreciate the desire to make
the system usable by everyone without having to add font packages, but the
tools for using the included Ethiopian fonts aren't included. If you're not
going to include the tools to use the fonts, don't bloat up users' hard
drives with 50+ MB of fonts! Geez. Add to that the dependencies which many
packages have been compiled — e.g., requiring samba to run mplayer. Little
thought given to users who may not install/keep samba. Like the security
issue noted above, that means more work compiling myself. And I was trying
so hard to not do that on this ancient laptop.
Also, the included wallpapers and icons aren't what I consider light or
fast. They're pretty heavyweight compared to other options. This is
noteworthy when considering the 82 lines in .jwmrc with icons — some of
them being scalable, some of them being quite large, and the menu icon
itself being over 40kb. All of that crap loads to RAM and causes performance
issues as jwm has to scale the various and sundry icons. I realize my own
jwm configuration is spartan and probably not to most users' tastes, but
there has to be a reasonable approach to this. And I'm not arguing for
removal of all icons from .jwmrc, just use sensibly-sized icons that don't
cause users to use the same amount of RAM to use jwm as they use for Xfce!
Third, there are several bugs to be sorted out. For example, the
setconsolefont script is broken (line 41):
/usr/bin/setconsolefont: line 41: $REPLY: ambiguous redirect
putfont: KDFONTOP: Operation not permitted
While that's not particularly serious (setfont /path/to/consolefont), I've
had several getty issues on my laptop. Suspend/tuxonice doesn't work and
causes me to lose all video whether in X or console if I go idle. If I kill
X, I don't get any video input — just a blank screen. I can blindly type
"startx" to get back to X but can't view any console output.
Fourth, another sort of minor thing that isn't very minor: I also noticed
that my wireless router light would continue to flash for a few minutes
after I shut down. I found that /etc/wireless/interface.conf listed
INTERFACE="wlan0" instead of eth0, which is where my interface was set up
using VASMCC — Vector's own tool.
There are a few other issues that I've wrestled with but these are the ones
that come to mind. While I still think Vector is commendable and headed in
the right direction, I can't recommend it to inexperienced users. I also
think in some ways experienced users wanting a Slackware-based desktop would
be better served using Slackware in the first place. The packages are going
to be about the same. I've already recompiled more things than I wanted to,
and here I am thinking of removing X altogether and rebuilding the system to
pare down the bloat. I just think Slackware's minimal install with a few
select packages is a more sensible choice than Vector for someone wanting a
low-resource system.
I intend to check out Vector's lighter project soon. Maybe that will be
better, maybe not. I don't think it's adequate to offer jwm and/or fluxbox
and call it "light." There's more of a need for a paradigm shift to it than
merely remixing apps and window managers. Anyone can do that and the world
doesn't need more sub-distro remixes masquerading as "new" distros. Will it
actually use distinct, separate packaging with minimal associated bloat? Or
will someone ostensibly update to full-blown Vector when installing
something from the repo because the apps aren't compiled with forethought to
keeping the system as small and unbloated as possible?
If it's the latter, no deal. If not, there won't be any need for me to
continue with my low resource slackbuild. Or to be a little more cautious
about recommending Vector without qualifying it.
EDIT: I resolved the issue with losing ttys after killing X by modprobe
vga16fb (I don't need framebuffer before X but I do after?). I'm still
sorting out tuxonice. Or giving up on it. I'm also still waiting for
activation for the Vector forums. Registered once, just hit my second
'resend activation code' button today.
documented on: April 21, 2008, lucky
Reconsidering Vector
> Have you looked at Zenwalk Linux? (http://www.zenwalk.org/)[]
Yes, I tried the (last? only?) beta for 5.0 before the RC was released and
before trying Vector. Same problem I'm complaining about Vector, too — the
packages really aren't built with lower-end users in mind. The two aren't
that different. Both are Slackware-based, both have similar default mixes of
apps, both use Slack packaging.
Please correct me if I'm wrong and Zenwalk packagers are more inclined to
reduce/minimize dependencies than to add in every possible feature.
Zenwalk core edition is on my list to try as a base for the lower resource
build above that (choice is between that, Vector without X, Slackware
current minimal, or start from scratch).
documented on: April 21, 2008, lucky
Zenwalk & DW awarded
> Ladislav from DistroWatch has awarded 200 EUR to Zenwalk...
It's not necessarily a bad thing to donate to Zenwalk, but for me Wolvix is
much more zen.
-
knowing that (1) the GPL requires you to either make the full sources available, or to make a written offer to provide them in a reasonable manner; and (2) the Slackware tradition (which Zenwalk should inherit since when it was MiniSlack) is to simply offer the sources for download;
-
knowing that Zenwalk doesn't offer any recent sources (the available sources are from 2006);
-
knowing that Zenwalk doesn't publish any written offer with means to get the sources;
-
knowing that this infringes the GPL (see the MEPIS case in the past);
-
it's up to Ladislav to find a moral justification for awarding 200 EUR to a distro (not thrilling, but not a bad distro either) that doesn't observe the GPL!!!
-
In contrast, Vector and Volvix *do* offer the full sources for download! Eh?
-
Maybe it's worth noting that Dropline GNOME lacks the full sources; and LinuxPackages.net also is binary-only;
-
In contrast, Slacky.eu (including Slacky GNOME) is offering the full sources too.
In short, Slackware-related, DW has awarded: Vector, NimbleX and Zenwalk,
but no one can get the current sources for Zenwalk (if they're hidden,
they're extremely well hidden!). In the meantime, Wolvix, another
installable LiveCD based on Slackware, was not awarded anything!
Ladislav, the next time please do your homework!
documented on: 2008-01-07, Beranger
