If you ask a Slackware fan why she likes Slackware, she will probably mention Slackware package management as one of the features she likes. In what way does the Slackware package system differ from most other package managers? In one word: simplicity. In three articles I am going to cover some important aspects of Slackware package management. In this article I am going to show the anatomy of a Slackware packages. In part 2 and 3 I will cover the package tools and the process of creating a Slackware package.Plain old tarballs
Before getting into the details of Slackware packages I would like to explain a few basic characteristics of Slackware packages. These days most package managers are quite complex. For example, the most important feature of many package managers is dependency handling.
This means that if a package requires other packages the package manager will take care of installing them too. Most of the times this works, but dependencies can get a bit annoying. For example, if you install software that is not in the main distribution, version numbering
conflicts can arise. The Slackware package tools do not handle dependencies. The means to handle dependencies does not exist in the “format” of Slackware packages either. This can initially scare away users, but it is (at least in my opinion) more flexible and provides more freedom. Since there is no dependency management at all you are in control.
Well, what is a Slackware package? A Slackware package is a tarball (an archive created with tar and compressed by gzip) which contains information about the package and an installation script. The information about a package is stored in two ways, first of all in the filename
of the package, besides that the tarball contains a desctiption file. Both will be covered lateron. Last but not least a package contains an installation script. This script is automatically executed when installing or upgrading a package. Most packages only use an
installation script for making symlinks. Correct Slackware packages do not have symlinks in the tarball, symlinks are set up using the install script.
The package filename
The package filename provides some information about the package. This information is also used by the Slackware package tools, for example to decide whether some package is newer than the installed version. A package filename has the following syntax:
name-version-architecture-revision.tgz
The different variables in a package filename are seperated by
by a ‘-‘. Naturally, it is not wise to use the separation character
in one of the variables. The filename is usally in lower case. The
first variable defines the name of the package, usually this is
just the name of the software. For example, for Mozilla this is
‘mozilla’. The second field determines which version of the software
the package provides. This is usually used te determine when to
upgrade a package and when not. The third field specifies the
architecture of the package. Nowadays the official Slackware
distibution only supports x86 machines. Up to Slackware Linux
9.0 packages were compiled with ‘-march=i386’, so the name of
this variable is usually ‘i386’. Starting with Slackware-Current
after Slackware 9.0 support for 386 machines is dropped due to
some glibc issues. So new -current packages are compiled with
the ‘-march=i486’ gcc parameter. So, the architecture variable
is ‘i486’ in Slackware-Current. Last but not least the revision
number is specified. This is used when a newer version of a package
is released, but the package is still at the same version.
Usually this parameter is ‘1’ and increases after revisions.
More information about the package is in the /install/slack-desc
file in the package tarball. This file contains the package description
which is shown during the installation of a package. If you have
ever installed Slackware you have probably noticed these descriptions
during the installation. Basically this file just contains the
description on multiple lines behind a ‘name:’ part on each line.
I will discuss the slack-desc file in detail in the article about
creating a package.
The install script
Until we discuss package creation there is not much to say about the
install script. There are a few things you should be aware of. First
of all the script is in the /install/doinst.sh file. The second
thing I should notice is that, though symlinks need to be created
by the install script, you do not have to write the symlink (ln -s)
lines manually. The makepkg script can take care of this.
Some final words
This first article is not an introduction to pkgtools, but I hope
you have an idea what a Slackware package consists of. In the following
articles we will dive into package maintainance a little deeper. In
the meanwhile: happy Slacking;).
I’m a Slackware user (Ever since I started with Linux), and one of the things I DON’T like about Slackware is it’s package system. It’s not very fun compared to the systems that debian or gentoo have.
Slackware’s package system is one of the reasons I no longer use Slackware and have switched to Gentoo. Although it’s not JUST the package manager, but the availability of packages…a lot of people seem to assume if you run Slackware you compile everything yourself, and because of this also assume you wouldn’t find it helpfull to have a Slackware package to install. Unfortunately this leads to Slack’s package manager almost never getting used in the first place, and forced me to try to compile a lot of huge apps(like gnome2) myself.
Why don’t you use Gentoo then?
Yeah, it’s so simple people can’t handle
# emerge package_name
How simple can it get?
Except I’ve already got Slackware installed and I don’t feel like formatting
I don’t really see how it’s better than debian/gentoo models.
I still can download debs and extract them manually if I think dpkg isn’t doing its job right.
You can use Checkinstall ( http://asic-linux.com.mx/~izto/checkinstall/index.php ) to create Slack (and rpm, deb) packages from source packages. Super easy and works really well.
Slackware was my first linux and it has good quality but nowadays there are best alternatives like Debian (it is as stable as Slackware, have more precompiled packages, have easy update tool and it is made by a non-profit orgazization) or Gentoo (more customizable than Slack, more intelligent build tool).
I think that it is time to Patrick to stop Slackware Developmente and integrate the best features of it in Debian or Gentoo.
Talking about simple package management, take a look at the CRUX Linux distribution package management system (pkgutils).
It does not include dependency handling (thank god) and its package build files are simple and powerfull – If you need a package which does not exists, well then create it yourself – its that simple! and it takes little effort if your a fairly advanced/experienced user.
Visit http://www.crux.nu , try it out.
I wouldn’t even call it a ‘Package Management’ system…
Debian – apt-get update && apt-get dist-upgrade. Spend a few hours messing around finding all the little configuration booby traps left behind for you if you run Unstable.
Gentoo – emerge –update && emerge –update world. Spend a few days compiling everything in the background if you’re not fortunate enough to have a farm to do the compiling for you (still a few hours if you do).
*BSD – See gentoo except you do some cvsup and make buildworld foo.
Slackware – Upgrade? Whats an Upgrade? You do a Reformat && Reinstall. Spend about an hour putting your configuration back together. Laugh at everyone else when they do a distribution upgrade and have to work all the bus out. Get laughed at when you have to spend 20+ hours trying install a major software package (like KDE).
Redhat –
If you have apt-rpm: See Debian.
Otherwise: See Slackware.
Windohs – Do a Windohs Update. About 15 min to 1/2 an hour.
But in the long run you’re screwed anyways when the newest worm/virus/exploit/MS licensing agreement comes a knocking. You spend days upon days trying to disinfect your MS crapware servers….only to find them infected again a few hours later or end up paying out of the $%% (or most likely both hurray).
Moral of this story: They all suck. Use what you like.
As well as checkinstall, you can get ready-made packages at
http://www.linuxpackages.net
I find it funny that you criticise Debian unstable for doing exactly what it is supposed to.
A non-dependecy handling package system doesn’t seem to appealing coming from a Gentoo, Debian, and Fink user, as well as a dappbler in FreeBSD. I don’t see any practical benefits myself of having control over the dependecy handling. A lot of new system allow for multiple versions of packages too, so it’s becoming less of an issue. I read here that some Slackware users don’t like the package system. Well I’ve never used Slack or read too far into it, so I would like to honestly ask what other aspects of this distro appeal to you?
>> I find it funny that you criticise Debian unstable for
>> doing exactly what it is supposed to.
Criticising? I guess I am. I’m just annoyed at some of the brain dead choices package maintainers make when choosing compile options for packages in Debian Unstable. Namely choosing options that are both experimental and obsolete. I assume that they’d be able to change the compile time options and generate new packages for Unstable rather then having to wait all the way to Testing or even Stable to find out: Oh geez this is stupid.
I have thought about this a lot.
I need dependency resolution in my package manager, because in the complicated linux software world where everything depends on 10 packages, managing dependencies is too time consuming. If the distribution creates good packages, dependency management is more perfect than I could do it.
Think about this: you want to install the latest package X. Package X depends on Y. You have Y, but an old version. You want to upgrade it. Can you? What depends on the old Y? Anything? Can you remove it?
My point is this: if I can just type in a single command to do this install, and get back either “success” and be done, or the specific reason there was trouble (“can’t upgrade Y, Z depends on older version”).
Here’s what I have been very comfortable with (and I’ve dabbled with debian, gentoo, and mandrake):
Mandrake and urpmi are the best tools so far, IMHO. Here’s why.
(1) Most common software is this simple:
$ urpmi foo
All the dependencies are downloaded and installed, and if you have “played nice” with RPM, you should never have problems (I haven’t).
(2) If there’s software I need to compile from source, I can either get the .src.rpm from the urpmi repository and change the spec file (if it is provided with Mandrake rpms) or I can just write up a custom spec file and build a new RPM.
Yes, I have tried checkinstall, and I agree that it is useful, but I never liked the way it worked. There are quirks with things like ‘make install’ running ‘depmod’ and checkinstall assuming that the modules dependency file should be part of the package.
On top of all of that, I keep a list (/etc/backup.list) of files I have added or changed from the base install of all of the RPM files, so that I don’t have to back up all of /etc. Restoring my system was never easier. I no longer have to weed through an old /etc to see what I need to do in a new /etc – I now have a list of exactly what I changed, making restore trivial.
I have yet to find a better system, and I’m still looking.
-Serpent
Ive been using Slackware for a while and I’ve never really had package dependancy problems.
Maybe a package needs a dependancy, with Google, its just a matter of searching, downloading, and compiling.
Slackware is so generic, that almost any tarball will compile. Unlike Redhat et al.
Usually when installing programs, 1-2 dependancies are needed, its an extra 10 minutes, thats all.
Now, once or twice ive gotten dependancy hell where I couldnt resolve all the dependancies of the dependancies, but its not common at all (and there is linuxpackages.net for that) and Im not going to lose control of my system just to save 10 minutes.
Actually, I use Slackware’s installpkg and removepkg, as well as the “pkgtool” front end, quite often on servers. It works very quickly, and permits me to install gcc and other development tools as needed — and then remove them as soon as I’m done so that some creep can’t exploit them.
In rpm land you can upgrade by,
1. getting the latest iso and booting, They will upgrade your system.
2. Take the new package run rpm -Uh foo.rpm , and it will warn you if you need any more pacakges.
3. Use up2date to automattically update your system to the latest. I personally use a script with this to maintain the lates rawhide release on a development server.
4. If you hae a bunch of RPMS use rpm -Uh *.rpm and the system will sort them , determine the dependencies and warn of anything missing before upgradeing.
As for the comment of
“This can initially scare away users, but it is (at least in my opinion) more flexible and provides more freedom. Since there is no dependency management at all you are in control.”
try
rpm -Uh –force –nodeps foo.rpm
and you get the same damn thig.
You want to rebuild the world? A little tougher.
for A in `ls -1 *.src.rpm`
do
rpmbuild –rebuild $A
done
and off it goes compiling away, System compile options are in /etc/rpmrc or /usr/etc/rpmrc. (For an alpha this usually meand -lcpml
Just my 2 cents.
Donaldson
Disclaimer: Scripts typed above were not tested, they may not run.
Disclaimer 2: I do a lot of alpha support for RPMS and I like it, I think I would like gentoo but I get the same effect for RPMS and up2date
Hey Donaldson,
iirc, you can just do:
for A in `ls *.src.rpm`
the -1 is implied when ls is being run in backticks.
Just a random observation to make the sample a bit simpler.
Lately I keep reading that because apt-get is available for rpm , debian has lost its edge on package management. That isn’t true.
apt-rpm, urpmi etc. don’t cut it because:
– There is no policy that dictates upgradability
– There is no culture of flaming anyone disregarding this policy
– Debian-servers have massive bandwidth, hobby apt-rpm repositories have little.
– The latest Red Hat-specific goodies won’t be avalaible on a up-to-date RH7.3 repository.
– An RPM lacks virtual packages, ‘provides’, ‘suggests’ and ‘recommends’ dependencies. These are needed for flexible dependency handling.
– Most RPM distros I have seen do not respect your personal configuration tweaks on a upgrade.
And Debian will continue to have the best package management system, because of some recent developments:
– apt-listbugs: grabs bug-reports to warn you if necessary.
– apt-src: build-dependency solving done right so gentoo-users who don’t want to build EVERYTHING from scratch have an alternative to emerge. Efforts are made to make building apps from an deb-src repository a consistent, easy experience.
– debconf (system to ask configuration options and remember them) will be fast (cdebconf) and used wherever apropriate.
Redhat –
If you have apt-rpm: See Debian.
Otherwise: See Slackware.
I think it’s more like
– Insert new installation CD
– Select upgrade of existing system
– Pray.
Hello,
Okay I made a mistake up2date was my old method for rawhide. My mistake, (I’m switching servers this weekend and have limited acces to my files.) here is the correct script:
# !/bin/sh
cd /usr/src/redhat/RPMS/
autodld –url rawhide.redhat.com/pub/redhat/linux/rawhide/alpha/RedHat/RPMS
It’s from autoupadte: homepage:
http://www.mat.univie.ac.at/~gerald/ftp/autoupdate/
2. On the issues of find package dependencies using google. I suggest under an RPM system use rpmfind.net. The lack of a good packageing system reminds me of windows, beos, and the SLS distribution. Windows dosen’t have a clear idea of upgradeing packages. BEOS did’t have a very good system at all. and sls use the tar system.
3. One of the best parts of rpm is if you in the middle of tracking down an issue and you find a file that contains some information and you wish to know where the file came from: rpm -qf file
or my favorite rpm -qf 1which autodld` I have also use this to verify lib direstories looking for rogue files.
Donaldson
RE: Ryan
Force of habit, I’ve been burned by scripts for so long I over specify anything. (Sun OS 4.0.3 was mean to me)
RE: Why debian still has the greatest package management in the world
1. An RPM lacks virtual packages, ‘provides’, ‘suggests’ and ‘recommends’ dependencies..
Either you need a package or you don’t. RPMS can either request a package or request a specific package by number. Optional packages are just thought and the rpm script can teel you when installing about any additional packages you might want.
2. Most RPM distros I have seen do not respect your personal configuration tweaks on a upgrade.
I have always seen the oppsite. It leaves the old files alone and places the nwe file as foo.rpmnew, Recently I have seen the old file being moved to foo.rpmsave. I like this method cause on my rawhide system I will do a find once a week or so to smooth out any compatibility issues.
RE: Other
3. Compile time options are passed down for RPM’s so you can recompile the world with umm aggressive options..
I would like to see better management for RPM but this articles idea of cutting features off of it is bunk. I can cripple RPM’s to act like tars but why in the heck would I buy an sports car and take off the wheels.
sigh
Donaldson
> I think it’s more like
> – Insert new installation CD
> – Select upgrade of existing system
> – Pray.
Hah hah
When you uninstall a Slackware package, does it remove the symlinks created during install time?
Also install Mozilla without some of the GTK stuff installed won’t work, how do we handle this? Will we find out in part 2 or 3?
I use Swaret http://swaret.xbone.be/ its like apt-get
> When you uninstall a Slackware package, does it remove the
> symlinks created during install time?
Whatever files that are listed in /var/log/packages/package-name will be removed, unless they’re listed in another package.
> Also install Mozilla without some of the GTK stuff installed won’t work, how do we handle this?
I think Mozilla needs that stuff depending on compilation options, but as there’s no dependency checking, it’s up to you to install all the requirements, (which isn’t that hard to do really).
> Well I’ve never used Slack or read too far into it, so I would like to honestly ask what other aspects of this distro appeal to you?
I’ve found Slackware one the easiest and straight forward distributions to use. It gives me control over my system and has always come across as being very stable. I think if you’re the type of person to want to know precisly what’s happening on your system and want to learn about the Linux OS, Slackware is for you.
IMO, Mandrake’s URPMI is what makes it way better than RedHat. All this crap about how good the desktop looks and whether Bluecurve or Galaxy is better is just noise. When all is said and done, I can make the desktop look anyway I want it too, but between the main and contrib trees, most decent software has Mandrake packages, and if you have your mirrors correct, installing a new package is as easy as Debian:
urpmi foo
and to apply all security and bugfix updates,
urpmi –auto-select –update
URPMI is even the recommended way to install Cooker now is to install 9.1 and then use urpmi to bring it up to date.
/g
It gives me control over my system
I agree with you, but you first have to learn how to control the system, after that things should be alright.
I hope those are the things that the next parts cover.
John Blink wrote:
> I agree with you, but you first have to learn how to control the system, after that things should be alright.
For me, that’s a not a bad thing as I’d rather learn than have no control or understanding.
Maybe it’s just me, but all that article did for me was to rule out Slackware as a distro for all of eternity. No dependencies? I’ll take Debian or RedHat, thanks. The last thing I want to do is download and install a tgz, just for it not to work because it couldn’t find 50mb libwhatever.so.1 in a package I don’t own.
-Erwos
I’ve always preferred Mandrake but I was giving Redhat the edge for the first time with Redhat 9 edging out Mandrake 9.1 based on their desktop and the inclusion of the new NTPL threading libs.
I even got to like their umpteen redhat-config tools except for their package manager. It was just too restrictive; as I was low on hard disk space on my laptop, I would try to remove
packages that I didn’t need only to have the package manager tell me it would remove an entire cluster.
I started using apt-rpm but I started to get periodic corruption of the rpm database and would need to re-initialize the database in order to use rpm again.
Apt4rpm configuration can be a bit tricky.
Urpmi, on the other hand, just plain works.
I was turned off by Slackware Linux 2 years ago when I
discovered that it was affiliated with a cult religion
that goes by the name of the “Church of the Subgenius”
Nobody really talks about this. Some may not care if he
worships Satan himself. However I do and would never use
it anyway because it is an inferior distro to Debian and
Gentoo.
> Slackware – Upgrade? Whats an Upgrade? You do a Reformat &&
> Reinstall. Spend about an hour putting your configuration back
> together. Laugh at everyone else when they do a distribution upgrade
> and have to work all the bus out. Get laughed at when you have to
> spend 20+ hours trying install a major software package (like KDE).
That is funny, I upgraded my Slack8.1(1 laptop, 1 tower and a Server) to Slack9.0 without the need to format the disk…
Now how did I do that?? There is an UPGRADE.TXT in the first CD… If you care to read it…
Slackware got it’s name from the Church of the Subgenius: http://www.subgenius.com
If you can take The Church of The Subgenius as a serious
detrimental-to-your-health-type cult (somehow!), then you will find that followers don’t worship Satan, but a cartoon head called Bob Dobbs. It seems pretty hard to take the CotS as anything more than a joke when the online membership form has the following:
SIGN HERE: ________________________________________
(Do not attempt to literally write name. Merely concentrate on the blank line and think “Dallas.”)
Thinking that the cult of the sub genius is a real cult is similar to thinking that Mickey Mouse ™ is a real mouse.
People here are complaiing that Slacks’ Package manager doesn’t handle dependencies. But in the real world there are not that many dependecies. I mean some packages say gcc and glibc are dependencies, but what real system doesn’t have them installed? It sounds like some of theses RPM install people don’t even know what is needed for a package or what is in one.
The one thing about Slackware is that you understand what is going on and can learn to fix it. If I want to install a package that is only available or another distro I can pull it apart and turn it into package that fits my system. Most other distro users at this point complain that the package is not available for their distro. But the truth is their distro is not allowing them to do it. Slackware doesn’t hold your hand so not only can you do the wrong thing but you can actually go ahead and do advanced things that othert distros cannot.
You might say that your distro lets you but the mentality behind its users is such that there is no easy way to do it and the users are not trained in such things.
To upgrade slackware you can simply do a upgradepkg *.tgz in each set directory. How hard is that?
1. RPM corrupts it’s database.
A: THis is an known bug and the fix has already been issued. The easy fix is to go to /var/lib/rpm and delete the 3 data base temporary files. Look for 2 underscores. No need to rebuild a database.
2.it would remove an entire cluster.
A: Don’t know what you tried to remove but sounds like it was either a core rpm or the cluster itself.
3. Dependcy generation.
A: I’ll have to go check again but there are ways to automatically generate the dependencies based of ldd and rpm-qf (cool concept if you ask me) and this helps the problem of pacakgers not requesting all the correct dependcies or the correct version number.
4. RE: Dependcies.
THe issue is not just is libc installed but is it the right version, did a developer have an error, change an interface etc.
5. Other notes:
I may not like what redhat dud to some scripts and I don’t use bluecurve at all (wmx or pur enlightenment here) and I use vi in /etc more than not, however they define VAR. They have but a lot of effort , work into their distributions and it really shows.
Donaldson
One thing I do dislike about rpm is an src.rpm can only generate on type of binary rpm.
Example: I have cat.src.rpm
I want it to make cat.alpha.rpm and cat.doc.noarch.rpm
but I can either have the .alpha.rpm or the noarch.rpm. That blows in my opion.
Doinaldson
If you like Slackware Linux you use it, if not you don’t. I’ve started with RedHat 4.0 and worked with trough the years, but by the time when Slackware 8.0 came out I’ve switched and never looked back. It is a nice straight-forward distro, easy to use and rock solid. I use it on my desktop and my Laptop as my main OS, and I am satisfied with it. It just works, and has very few bugs compared to the big commercial distributions. In a few emails that I’ve exchanged with Patrick Volkendirk I’ve understood the ideas behind Slackware Linux. Patrick aims at simplicity and does a great job. Slackware realy shows how simple Linux can be. Of course, it depends on taste and on other things, so everyone uses the distro that fits their needs.
“If you ask a Slackware fan why she likes Slackware…”
I don’t wanna sound like some crazy dude, but this Kok guy is realy asking for it: Why the hack “she”??? Not every slackware user is a woman/girl you know? Both man/women are using it. On the other hand the article sux. I’m a die-hard slackware user and I know there is not much to talk about package management. Its plain simple. It could use some minor improvements wich realy would be some bug fixes, but its ok the way it is. As for Joe User who complains about Slackware Linux, he shouldn’t , just go and grab another distro.
Hail B0b!
# emerge -C slackware
“Slackware 9.0 support for 386 machines is dropped due to some glibc issues.”
Untrue!!! Untrue!!! Untrue!!!
The i386 support is dropped because of two reasons:
1) gcc 3.2.x generates i386 code using i486 opcodes. This has been fixed in gcc 3.3 but the i386 code generated with 3.3 is incompatible with i386 code generated by older versions, so Slackware 9.1 will be i486.
2) for 386 machines everyone uses older versions of slackware linux.
Maybe you didn’t know, so I won’t say anything bad here:) Just joking…
“Slackware 9.0 support for 386 machines is dropped due to some glibc issues.”
Untrue!!! Untrue!!! Untrue!!!
The i386 support is dropped because of two reasons:
1) gcc 3.2.x generates i386 code using i486 opcodes. This has been fixed in gcc 3.3 but the i386 code generated with 3.3 is incompatible with i386 code generated by older versions, so Slackware 9.1 will be i486.
2) for 386 machines everyone uses older versions of slackware linux.
Maybe you didn’t know, so I won’t say anything bad here:) Just joking…
The last time I tried slackware, I did a full install, complete, everything, each package on the CD. Still, Nautilus did not work because libcdda was missing 🙁
However, Slackware (just like OpenBSD) is very friendly by sending an introductory (how do you write that) email to the root user after installation, with hints about configuring the system and such.
Where OpenBSD is even so friendly to have a “help” command (alias to “man help” I think) which explains some configuration options and goes over the most importand command line utilities.
Debian Package Management is great, especially thanks to dpkg-reconfigure. With this application each package can be (re)configured as needed. Compare: in SUSE Linux only certain packages have a YaST2 frontend, for example.
I started with Suse, then tried RH and Mandrake, settling on Mandrake 8.2 for a while. Problems with Mandrake included bloat, GUI tools not functioning as they should (requiring hacking by hand), software breaking, no USB mouse support in install. If the only safe way to fix the init scripts, cd writer etc is to hand edit, why not just cut out the bloat? So I went for Slack.
I run Slack on my desktop now, and have Debian on a secondary machine that will one day be a server. Both show much less bloat and the Debian one is lightning fast – but I’m still climbing the learning curve on apt. Slack will serve me for a standalone machine, Debian for a server when I need to upgrade for security without hassles.
Package “management” is a strong point? Kinda. The distribution seems to be production stable (unlike all of the commercial distros I’ve tried so far), clean, and (like Debian) makes a little effort in sticking the software in a logical place on the tree. I stick 3rd party software in /opt and make a package at the same time with checkinstall if I need to reinstall. Compiling is much less of a headache than with Mandrake. The key to upgrading is keeping copies of fstab, inittab, rc.modules, XFree86config etc somewhere where you can refer to what you had in the last install. I’ve no doubt that I could reinstall in a couple of hours with no headaches whatsoever. And nothing’s broken yet.
I like what I hear about the latest Mandrake though – I’ll try it when I build a new box.
There are no probs at all with Slackware’s package management system – it does it’s job as it needs to.
I think the reason people find the dependancy stuff an issue is because RPM’s make such a hash of it. I tried redhat for a bit and had a nightmare trying to install/remove packages due to dependancies which shouldn’t actually affect anything else anyway. And I’ve never had nautilus refuse to run.
The best way to have slack up and running is to make sure you install all of the libraries. Any others you need can then usually be found on linuxpackages.net (which i only found out about recently – i’d used slack for two years without it) and if you’re in the UK you can buy Linux Format which has all the big stuff you need such as the latest versions of SDL etc.
People ask slackware users why they still use it… to that I have no answer but this : try it yourself.
Slackware is what Linux is supposed to be – and i’ve always found it easier to use than other distros – even when i was a complete newbie.
Other reasons for Slack:
1/ The point of Debian (or Gentoo) is defeated if you have a crap internet connection. Slackware fills a niche for the hardcore linux tweakers that the commercial distros don’t provide, with a great default install from CD.
2/ If you do have a good internet connection, then Dropline Gnome (http://www.dropline.net) rocks.
Computer program is not smart enough to resolve all the dependency problems of growing packages. When you try to upgrade a bunch of packages, ports based system complain occasionally and rpm are screaming all the way.
Debian has the most robust package management system, but debutils make simple thing complicated, that’s the problem.
Slackware is my first distro., then RH/MDK->LFS->gentoo->LFS, and back to Slackware. I build my own system base on a basic setup of A/AP/N and resolve the dependency problems myself, just have too much time to waste
Well. I would just like to add that I have learned more about Linux and how it works in the 6 months since using Slackware, than I did in the 2 or so years of using the bloater distros..
The Slack tarballs are fine by me, they work great and I know exactly what file is being placed where – it’s great. I maybe one of the lucky ones, but I haven’t really suffered “dependency hell” with Slack.
I couldn’t care less what apt or rpm can do – if you like that sort of thing then enjoy ’em but don’t chastise people for using something different. Each to their own!!
It’s like listening to kids at school this…
Mine’s better than yours.. na na na na naaa na! pfffft!
Well.. as usual .. an article attempting to explain a feature in a distro leads to a flame fest. I would have thought it would lead to ” nice article” , or maybe ” why is this article here?” But no.. as usual.. its lead to “But gentoo, but gentoo but gentoo but gentoo!!!!” Im a slacker. I like it. Since using Rh and MDK (both good distros) ive decided that rpm is a pain. At the same time. i dont want to be dependant on bandwidth for maintaining my distro. Ide say i compile about 40% of what i install. works fine.. If i can find a slack package..thats fine too…. ok.. i tried to resist.. but i cant.. Gentoo users: Get a Life.. Have you ever kissed a girl?? Go see a movie..
For me, I find nothing wrong with slackwares package management, all it does is unpack a tarball with precompiled binaries… Its fast simple, and most of the time if you download a package at linuxpackages.net someone will have already made packages for dependenices — easy as pie. And if not, go download the source and compile it yourself! 70% I’ll just compile my programs even if it is a 533MHz, it doesn’t bother me at all. Another awesome feature about slackpacs, as there is only ONE package unlike RPMs where there is the base binary and the -devel packages. God I hate those. I took 3hrs of my time to download RH9, but decided not to install it cause I remember how bad the RPM system was last year when I had RH7.2.
I don’t care for debians pkg management either, it seems too complicated and akward, I’ve installed Debian Sid a couple of times, both times resulting in a libpam0g error when apt-get dist-upgrade.
I can’t say much about Gentoo’s emerge, I’d like to give it a shot but I can’t at the moment because my mom is taking some online classes (windows) and I don’t have days to setup my system (533 celeron….slow!). And I will definately stay away from gentoo when they switch to RPM instead of emerge src stuff. I hate RPMs — thank god for source!
Sounds like you are talking about RPMS
src.rpm is the tar ball plus the patches to compile it.
i386.rpm is the precombiled binaries for the install.
Donaldson
Its all about keeping it simply and remember that you and everybody you know are stupid.
I’m serious. If you think you’re smart, you’ve missed the point.
But don’t let me stop you.
marcm wrote:
“In a few emails that I’ve exchanged with Patrick Volkendirk I’ve understood the ideas behind Slackware Linux.”
Dude, his last name is Volkerding. You are freaking idiot and a bullshit artist. You claim you are a “die-hard” Slack fanatic, which is a damn lie. Any halfway-decent Slack hacker knows Pat’s last name.
You’re a lame-ass.
Good article. After reading some of the comments here, I had to throw in my 2-cents worth…
What I love about Slackware’s package management system:
Simplicity. it’s EASY. Especially if using Checkinstall.
Dependencies, shmependencies. On the *rare* occasion that I don’t already have a dependent library already installed:
A: ./configure usually lets me know right quick if something is missing. If not, Make does or I can look at config.log.
B. The README file or INSTALL file in almost any given package will nearly always say if there is an unusual or special library or dependency required. RTFM First! Duh!
IMHO, people who are too lazy or careless to even read the README and INSTALL file before installing a package ought to go back to Windows. And if I have even a CLUE what is installed on my own computer(s), I usually know right off if I have it or not, or I can ls /var/log/packages/<lib-blah*> or locate lib-blah.so or, if it is buried in any existing packages, grep slackware/MANIFEST.bz2 on the Slackware install CD.
I can even resort to ldd /usr/bin/blah.
But, ohhh! That’s too hard! <whine> whine>
In any event, totally relying on some quirky dependency-checking automatically-installing and reconfiguring program that may or may not screw up something else or put something where I dont’ want it is a great way to NOT know how your software interdepencies actually work!
C: Self-Reliance. I don’t like being so dependent on some package-maintainer somewhere. Maybe he used some oddball trick or patch to get a package to work and then dropped out of sight without documenting it. Now I need to get his oddball patch for a library that needs updating so that the upgraded program that depends on it will compile which needs a needs a newer version of… it is generally easier to get the straight story on what is needed from wherever I got the source package… not via some “package maintainer”. Also I can usually build a Slackware package myself much quicker than searching for such. I *can* use Google.
D: And speaking of source packages… What is the friggin point of a “source RPM”? Isn’t it usually just a tarball converted to rpm? Isn’t this a little redundant? What? It has special instructions for building a source RPM package from source?
I’ve use Red Hat since v5.1 and have Red Hat 9 working fine
on one of my computers and I have Debian Woody running on two others. They are “ok”… but whenever I want to do something that requires knowing what is going on, I do it on Slackware. I’ve used or am using Knoppix, Gentoo and several other distros, too and I always come back to Slackware for the real-world stuff. It just works. It works with everything I’ve thrown at it, and I’ve thrown some pretty wild stuff at it. I’m running the latest OpenOffice betas, Mozilla-1.4 with all the usual plugins including Enigmail, Calendar, etc., I’m running OpenVPN tunneling to another lan across the country, lot’s of cool games, WineX, VMWare, LDAP, IMAP, Evolution, etc. etc.
Slackware is always quickly updated with the latest stable releases and security patches and, as I run Slackware pre-9.1 (current) on all my Slackware boxes, it is pretty much right on the bleeding edge… and, amazingly, Slackware-current has been *more* stable than any other distro I’m running. I don’t even want to go into what weird stuff my Redhat and Debian boxes are doing… they are in dependency hell… while my Slackware boxes run clean as a whistle.
What I don’t like about Slackware’s package management system are just some very minor annoyances:
I’ve made hundreds of Slackware packages with both Makepkg and Checkinstall… and even “by hand” with tar and gzip.
Sometimes the slack-desc file is apparently inconsistent between Slackware’s own Pkgtools and Checkinstall such that the package descriptions get mis-formatted. Also the size of the description is too constraining. I nearly always put the url where the source file came from and list any oddball dependencies the package might need in the description file… but often run out of room and have to omit important information there that I’d like to have there.
Also, I do wish Slackware’s package tools had a standard apt-get like utility to install Slackware directly from the net… I know there are several slack-get type programs and scripts available from various people… but I’ve seen those come and go with various versions and releases of Slackware and they aren’t really “official”. Of course, I run Dropline -Gnome on some of my computers, and it isn’t really “official” either… but it works pretty dang well 🙂 and at least I can install the latest Gnome2 over the net with it.
Anyway, don’t sell Slackware short. It is one awesome distro!
Cheers –
Chuck
just wanted to be the first to say i love the pkg system since nobody else seems to like it……
RPM = HELL
Gentoo = ok system…..still…whereis the .tgz file :>
FreeBSD = Ports rock
Slackware = awesome pkg system…no deps, no dep error messages…no nothing, puts me in control….RPM tries too much to be like…….W*ndows…….,)
Slackware packaging is simply the best. I don’t like the fact that other systems (like debian,mandrake,gentoo,rpm in general) expects me to be STUPID. I don’t want to be forced to install library X. I do know how to compile it by myself with optimizations _I_ like and newer version than the requirement if _I_ like. Sigh, people are just getting stupier every day…
and for emerge/apt-get crap:
there’s Swaret for Slackware that does the same thing(s).
(if you really need it)
That there is a 3 part article about the Slackware package management system is anathemical to the claim that the system is “simple”.
The initial flaw, call it a birth defect, it the dependency problem. Any system of mamagement is handicapped from the start. It is a Linux problem.
If you don’t like Slackware, or find it doesn’t suit you, then switch to a different distro! Those of us who have used it for years have come to like (love?) it for what it is: a stable and _secure_ OS (how often to you see Slackware mentioned on the Security Focus http://www.securityfocus.com website??). I mean, really, you’re talking about doing away with the oldest (still in production) linux distro out there. Gimme a break already!
Myles
You guys obviously have no idea what you’re talking about. Why would anyone compare Slackware to Debian or Gentoo? It’s a whole different league.
I for one DON’t like gentoo’s portage system at all. If you want things simple, and you don’t want to get your hands dirty, then this might be the way to go.
Slackware keeps it simple with the slackware packages. It’s clean and installs fast. It is also easy to uninstall or to upgrade. You don’t have to watch your computer compile for you (gentoo) but you can get straight to work.
And please don’t get me started on Debi@n. The names the developers define, like “superformat” (now integrated in many distros) keep your mind of the basics, and the basics are what people NEED to know.
If you want a clean, simple, fast system which puts you back in control, then I advise you to consider Slackware.
If not, listen to the pussies above, and use systems like gentoo, which are experimental, but in no way usefull to the corporate world. I don’t think it is usefull for me as an individual either, but I guess that’s just my opinion.
One last remark. What’s the deal about the “lack of packages” all about? This is not true AT ALL. Packages are easy to come by (www.linuxpackages.net for example). For example, I needed Ximian Evolution-1.4. This was easy to come by via linuxpackages. Emerge (gentoo) users had only access to the 1.2.7 version…
I hope people new to Linux choose a good distro, imho Slackware is the way to go! Thanks!
The simple reason for slackware not _needing_ dependency tracking is the fact, that slackware provides “full” packages. That’s why “slackers” hardly have any dependency problems. A vision uncomprehendable to debian users
With .rpm or .dep each programm is split up into 2-4 or more packages (common, devel, headers, …) which of course require dependency handling. If you have at least three times as much packages installed for thew same functionality, it of course will get a mess.
Further, Patrick seem to use way more sensible compile time options that debian or RedHat, who both try to put in _every_ option a programm possibly could offer, another factor in reducing dependencies.
Sure, its not everyones shoe, but I’m quite happy about the way it is – if it wasn’t for slack, I guess I wouldn’t be running linux at all any more.
swaret 1.2.3pre2 has Dependencies support now
http://swaret.xbone.be/