allend: Your suggestion was to install everything from the A/AP/D/L/X sets. To this I responded: if I was willing to do that, I could just as well perform a full install. I was pointing out the error in your reply. Some of you guys are hopeless.

Then you really should look up the definition of the word evident.

"you Slackware users"? Once again, if you don't consider yourself a "Slackware user" any more, then why are you posting here? Part of "moving on" is the "going somewhere else" bit.


Really? Then why do you want dependency management? Oh that's right, you want someone else to figure out the minimal set of packages you theoretically need to install so that the theoretical tiny set of packages that you use every day will work.

You should also look up "cognitive dissonance".

Pathetic is someone who doesn't use the distribution (and doesn't WANT to use the distribution) who posts sniveling cr*p about it. It's pretty bleeping obvious that the people who do use Slackware are just fine with it not having package dependency management.

You don't like Slackware? Fine, I'm glad you are no longer using something that made you unhappy. Why not go be a positive force in the forum threads of the distribution that you are currently using versus being a dick in the forum threads of a distribution that you aren't?

There are pages upon pages of HTML out there describing the various Linux distributions and their strengths and weaknesses. Some of us might possibly have used other Linux distributions and/or watched other Linux users dealing with their distributions. I have never been tempted to talk another Linux user out of using whatever distro they were currently using. They all have trade-offs of one type or another. The things that I value in a distro may or may not be the things that you value.

Slackware suits the people who use it and doesn't suit the people who don't. You've identified yourself as someone in the latter category. Fine. Good for you. Go away.

For the love of.. Did I come here demanding that Slackware start using dependency management? No. Did I come here trying to convince people that Slackware sucks or that they should simply not use it? No. Did I even say that Slackware sucks or that it is in any way inferior because it doesn't use dependency management? NO! I was simply disagreeing with a certain previous poster on a certain thing he said. So WTF is your problem anyway?

You feel the need to call me a dick and start some sort of online "fight" with me because I made you feel insecure by saying something "bad" about Slackware?

Why don't you go to the nasm, xpdf, firefox etc websites and check the requirements there? Surely that's the place to check them? Or Slackbuilds.org? Unless you're a GNU/Linux newbie, in which case I recommend doing a full install, where the tough decisions are already made for you by experts. I'm by no means a GNU/Linux or Slackware expert and I find it incredibly easy to pare the installation down to its bare essentials. I do that by combining Slackware packages with Slackbuilds and software compiled from source. I use this forum, Google and the various Slackware help sites. Perhaps I'm just lucky but I've never been stumped by a problem I met in Slackware. From day one I have found it incredibly easy to install software, and to edit startup scripts, and to find other help when needed. That's why it surprises me when people who know more about Linux than I do struggle with simple things like installing rxvt-unicode and Firefox.

Because it is useless and stupid to have a "automatic dependency solver software". See it for yourself with debian and fedora and their derivatives... Try to install a new package and see what comes together... tons and tons of useless crap.

Could certain people calm down please. Posixculprit was talking, I think, hypothetically. LQ is a discussion board and, unless I have lost my mind, that was the purpose of his post. No one is attacking anyone or any distro here.

my 2 cents:

fyi: have a look at required builder from Stefano Stabellini for an easy way to check dependencies ;)

if you are the impatient type you can go directly here :)

I hope this answers
so yes, like others said I think it's evident ("clear to the vision or understanding").
I think it's not proven.

I connect to what we were talking about earlier: you, as a user, think slackware is lacking something you need? develop it (I sound like Ballmer :D ).

have to say that during the years I have seen very good unofficial contributions and ideas from slackware users: that's one of the things I like most in slackware and his community.
and you can also learn a lot from these parallel projects, just looking on how they are implemented... don't underestimate the educational side of using slackware.

I don't understand why this devolved into flaming...I think I must agree with posixculprit here. The package series in Slackware's installer are not really grouped *too* well for dependency tracking...though it gives you a rough sense I suppose. That being said if I want to create a truly minimal install, I can't without going through every package (or searching for tagfiles for a Slackware minimal install in case someone else has done this for me). Anyone who says Slackware is better for not providing dependency information is in denial. It would be *much easier* if the dependency information was available officially, in case you want to create a nice small install that does not include anything extra (for a server, for example).

That being said I'm OK without a dependency list...I know enough about the packages in Slackware to have a sense of what is really required and what isn't, and I have a fairly minimal Slackware server running that I did not need any help with. However having dependency information (without having to pain-stakingly find it yourself) would certainly be helpful as long as the installer did not enforce automatic dependency resolution (otherwise you may as well use Debian). That being said creating that information would be a wasted effort for the Slackware team and most people that create a Slackware server, for example, should know enough about the different packages to build a relatively light install...but there's no denying that it is easier to create a minimal install on Arch than Slackware.

Perhaps on posixculprit's *subsequent* posts there may have been something to take issue with, but his point stands -- if you want to create a minimal install just supporting those packages, you can't without spending days of labour when you use Slackware. For anyone citing the dependency information for rxvt-unicode on slackbuilds.org...this assumes a full install of Slackware and is only useful for extra, non-Slackware packages. This is OK with me but it doesn't mean that it's better for not providing this information, though there are certainly third-party sources for this information. There really do appear to be Slackware users that delude themselves into thinking that there can be nothing wrong with Slackware...

sorry, but I can't understand.
after you installed all the packages marked as "REQUIRED", why the information that you can get from unofficial sources isn't enough? reading dependencies there you surely need only a handful of minutes to have the package list you need for your minimal install.

As I said, there are third-party sources for dependency information. They are just that, though, third-party sources.

and so? what's wrong with them? you can use them, and they just work for your purpose.

there are people developing this stuff and they maintain it firstly for theirself, because they are slackware users and they need it to work.

in my opinion, official or unofficial is relative, as long as I can see how it's done and it's functional to my personal goals.

okay guys, before you flame bait me for posting something that isn't mine, this question has been asked before many a times. (A good example is this noob caitlin bz who posted this garbage review: http://news.oreilly.com/2008/06/slac...est-versi.html)

So, check out sauls response because it hits the mark (its in the comments section, a couple down). I think its especially relevant considering the original posters debian background:


By saulgoode on June 11, 2008 4:26 AM

I deliberately ran this by a couple of other Linux professionals I'm friendly with this morning. They couldn't see your point at all. Neither can I. I can't think of a single reason why having no dependency checking in a distro would be desirable especially considering you can turn it off in any distro package manager I've ever used.

The disadvantage of having automatic dependency resolution is a byproduct of the package creation process. This problem is not readily apparent if one only examines the task of installing a package. It also can't be understood if one limits her viewpoint to just a single distribution cycle. One must examine the entirety of the distro's development, deployment, operation, and bug detection in order to apprehend the benefits of the Slackware approach to package management.

For those who may not be familiar Slackare package management, a Slackware package is basically a gzipped tarball of all the necessary files (executables, libraries, headers, config files, and documentation). When the package is installed, these filesget extracted and placed in the appropriate locations in the filesystem (and, if present, an optional installation script is executed). During installation a file is created which logs which files were added and where (for later removal or replacement, if necessary).

Creating a Slackware package is just about as simple as compiling the program and creating an archive of the generated files. It should be noted that during this compilation process all dependencies are verified (and this is generally quite trustworthy, or the program won't compile). If the resulting package is installed on another system (as is typical) and the program run, a failed dependency will be detected by the kernel and an error reported specifying which library is missing. This failed dependency, and the requirement that the user remedy the situation, is what Ms Martin refers to a "dependency hell" (it is my contention that she is fairly unique in making this association, as a web search of the term will show).

Contrast the Slackware packaging process with that for Debian packages (chosen as a typical auto-dependency-resolving distro). The compile process is pretty much the same, except that it is not uncommon that the packager must apply Debian-specific patches to the source code from the original project. While this might not involve dependencies in a direct manner, it does mean that a user wishing to compile source must fetch that source not from the upstream project, but from the Debian source package.

More importantly, if there is no Debian source package for the upstream project (or if the user chooses to use the upstream source to avoid modifications made by the distro), compiling upstream source can potentially run into a problem whereby unmodified project code conflicts with modified Debian libraries. While this may be a rare occurrence, it can be a complete disaster for a user trying to determine what exactly has failed (even using a step-by-step debugger). Again, while this is not directly related to the capabilities of the package management tools, Slackware package management encourages a strict discipline of not patching upstream sources. It should also be noted that Debian package tools do provide a way for the package to flag such conflicts, should they be foreseen (nonetheless, disposing of such discrepancies invariable requires manual intervention).

During the compilation of the source code (or afterwards, if the project's build system doesn't support it), the Debian packager must separate out the project's documentation files and the headers. This is because Debian guidelines promote creation of separate packages for the program, its documentation, and its header files (needed if other programs are to be compiled that interact with it). This differentiation of packages for a single project is not typically problematic, but combine it with the scenario described in the preceding paragraph and the opportunity for having mismatched patched and unpatched headers, libraries, or source becomes multiplied (and, again, possibly not detected at compile time, not handled by dependency checks, and not generating meaningful error messages).

Finally, it is the responsibility of the packager to determine the dependencies for the package, and whether those dependencies are depends, recommends, suggests, pre-depends, or build-depends; as well as any conflicts that might exist between itself and/or its dependencies (if handled properly, conflict specification can often prevent the problem of mixing patched with unpatched packages). This duty demands that the package maintainer be fairly knowledgeable about the upstream project and track the constantly changing interdependencies of the various components being used. A mistake made at this point can result in a package that installs properly and registers with the system that all is well, yet produces a runtime error which yields an unmeaningful or misleading error message.

Debian developers do a rather remarkable job of ensuring that such mistakes aren't made, or that they are caught during development and test. However, a lot of time and effort goes into verifying this -- the last Debian Stable was not released until after Testing spent five months being in the Frozen state. Other distros are not nearly so diligent.

There are reasons that Slackware is so rock solid and free of bugs. A major contribution is that expenditure of effort validating dependency resolution is greatly reduced and development resources can be focused on other activities.

Using unpatched, vanilla source code means that the dependency resolution, conflict identification, and corresponding testing performed by an upstream project can be relied upon within a Slackware deployment. Using unpatched upstream code virtually negates the potential for errors and conflicts with unmatched code between installed packages. The benefit this accrues to the installation of non-official Slackware software is one of Slackware's greatest features.

Another major benefit of the Slackware approach is that the GNU/Linux system, and the Linux kernel in particular, can be relied upon to produce meaningful error messages. However rare they may be, a mistake made by DEB or RPM packager can result in an error for which misleading messages are generated, or anomalous behavior the cause of which can be extremely difficult to track down. The Slackware development team may be small but this transparency facilitates the early identification of problems and their causes.

This transparency, along with the simplistic elegance of Slackware, provides the ultimate benefit that a Slackware user, regardless of her technical abilities, has the potential of eventually understanding her entire system (though admittedly it should take more than three weeks). Under Slackware, package management isn't treated as some cargo cult process where something magical happens behind the scenes; where a system's configuration is contained in some binary database accessible only through distro-specific tools. In fact, basic Unix command line tools are completely sufficient to administer package management (should for some reason one not wish to use the Slackware tools provided).

In closing, it is in my opinion unreasonable to recognize Slackware's remarkable stability and reliability on one hand, and then fail to recognize its package management approach as a major contributing factor to that reliability. Automatic dependency resolution holds many advantages, but it also comes at what some consider to be too great a cost -- true even if the administrator chooses not to avail herself of that feature. This may not be intuitively obvious but if one considers more than just the facility of "installing a package", it should be readily apparent.

It would be useful if there was a page on the Slackware site that gave a list of packages to have a barebones, bootable install - particularly for servers. Even just a text list or a line to say "just install the *Required* packages". On the other hand, Slackware (and other distros) is used in so many different ways that the team would spend all of their time writing lists and one-liners to cover everyone.

But I have a solution!!! Why not have a look at the "Slackware Minimal Install page on our wiki and see if there is any information missing that would be of assistance to anyone who needs it?

To validate this, posixculprit quotes
This is part ofThis is very basic propaganda technique - quote out of context (so that the subject, which is package division into sets, goes away), make an unrelated statement (since now it is possible to speak about individual programs), make an empty statement ("could you please list them" contains no data, but those willing to reply are free to add any data they want themselves) - enjoy the flood of posts.

Taken at face value, the reply should be: "list the package sets you programs are in, add sets these sets depend on, which is indeed evident, install the sets from the resulting list".

Taken as a (professional? payed?) attack, what a reply should be?

I not understand argument at all. Who winning?