Same thing could be said about cars. Nobody wants that. Even Henry Ford couldn't keep a lid on it. Thank God.

1 members found this post helpful.

As most of the posters on this thread, I was never terribly bothered by manually resolving dependencies. Then recently I read this thread and gave the tool a try. I have to admit it works very well, and saves a lot of time.
Mike.

1 members found this post helpful.

I've never had any trouble upgrading gimp on Slackware using Pat's script.

I actually find the lack of dependency resolution Slackware's STRONGEST trait. I like to know what goes on my system. If something has a ton of dependencies on top of a full Slackware install (this is rare in my experience), I will often search out a better alternative to that software.

In my Ubuntu days I would blindly install everything with apt-get. You really SHOULD know what is going on your system if you care about your system. Try:

I can't believe that meta-package. Absolutely absurd. No thanks!

3 members found this post helpful.

Thank's for everyone who replied. I'll postpone trying Slackware for when I have some spare time, it seems it couldn't be a sort of ready replacement for Debian, you'd got to have a good time to figure it out and configuring everything, specially if you're cursed with being an over-customizer of things. I had the guess that it could be not that troublesome based on the fact that Arch was pretty much "debian-like" to me, despite having read that it's harder, somewhat like Slackware.




Do those different installing systems play well with one another, or one's better off choosing one and sticking with it?

They all have the same result in that they generate a Slackware package. The only time you'll run into any issues is if you install the software outside of the Slackware package management system (like if you do a ./configure; make; make install).

If you can understand Debian and Arch then you should have no problem with Slackware. Just read the documents in the root directory of the installation disk, they contain a lot of info that will help with your install and initial configuration.

1 members found this post helpful.

Not to whine, but in Ruario's otherwise fine article,
are found the following misspellings:

down right should be one word: downright
"pairing down" should be spelled "paring" to pair is to couple, to pare is to slim down or reduce.

If it were not a good and useful article, I wouldn't bother pointing out the typo's
If I had the power to anonymously change the errors, wikipedia style,
I would have done so, silently.

As it is, long may the article stand. It's a good answer to the question, and provides a good overview of the
thinking behind how Slackware does things.

It provides a good counterbalance to the growing tide of types, lacking broad experience or
knowledge of *nix history who come in here with an underlying assumption that because Slack
does things in its own way, different from the big 4 distros, that it's somehow deficient.

Simple google search would have turned up that article. Not like it's new on the internet.
Slack's approach is also neither old, nor new, nor radically different, viewed across the broader
history of *nix.


.

At the end of the day, just try it and see what you think. That's it at the end of the day.

Each of us in here is obviously happy with how Slack does things. If we were at all dissatisfied, or
if Slack didn't work for us or do what we wanted, it's not like any and all of us lack for options as
far as distros go.

Personally, I like Slack for it's continued no-nonsense unix-ey approach. I'm not looking for a
windows or mac experience, and I don't use KDE or gnome. My personal ideal is 90's era unix.
So slack gives me what I want.

Try it, and if it gives you what you want, keep it. Clearly if dependency tracking were the issue
that some non-slack users make it out to be in their minds, Slack would not possess the user base
it has. Many distros have come and gone since 1993. There is a reason Slack stays around, and
it isn't because it doesn't do the things that the people who use it need it to do.

It has a different governing & development model than the other distros, but like I said, if it sucked
or didn't do what its users needed, it wouldn't still be around. Many distros have come and gone in
slack's lifetime.

The question is kind of an idle and frivolous one in light of Slackware's history and current userbase.
If the lack of dependency tracking rendered it unfit for the uses of even 30% of its userbase, it would have
been dead long ago.

.

3 members found this post helpful.

Wow, as a 20 year user of Slackware myself, Reaper has said this perfectly! In the beginning I thought "Man I suck at this, every time I try to compile something it fails because it's missing this or that, then the this or that fails because it is missing something or another." and so on... But eventually the thing finally compiles and I have a working piece of software! I would think "That was kind of a pain, I got it done but I'm sure I must have done it the hard way."

Of course I soon realized that I was right on track and that's just how things worked in "Linux"... having never played with anything but Slackware for years and years I never realized things like "apt-get" existed. In fact it's only been in the past few years that I finally played with Debian and used "apt-get" and now with FreeBSD using "pkg install". Are these tools easier and faster? Sure! Do I feel like I am in control of my system and really understand what I am installing? No way!!

Give me manual dependency handling any day!!

2 members found this post helpful.

'zactly....

The real question is, do I want to operate at this level, or some other.

Rest is details.

1 members found this post helpful.

I will add that those of us that started with Slackware and even more so, those of us that started way back in the early years, just take it for granted that that is how "Linux" works, like I mentioned in my post above.

Without a knowledge of any other way, we were not bothered by the manual dependency handling, kind if like back in the early days before cars had automatic transmissions, if you drove a car you had to learn to drive a manual shift transmission, you didn't give it a thought except maybe at first, "Man this is kinda hard!", but after awhile it became second nature.

Now we have generations of people who can't drive a manual shift car (mostly us Americans, myself not included as I prefer a manual shift)! Just like we have Linux users who can't manage dependencies manually. Don't get me started on Linux users that can't/refuse to use the command line! LOL Not real sure where I am going with this... but...

(Off topic: Reminds me of the news story of the car thief that car jacked someone with a manual shift car, he got in realized he couldn't drive the car, he then jumped out and ran away. )

2 members found this post helpful.

but it's really not the big deal it gets made out to be. Not at all.

1 members found this post helpful.

To quote a wise man/woman: "'zactly...."

There are no separate "-devel" packages in Slackware, which makes a HUGE difference. Honestly, it's the hunting down of small packages time and time again to keep up a core set of command-line tools that I expect to find on any sane Linux system that annoys me with distributions like Arch that pride themselves on giving you Full Control(tm) to build a system from the ground up -- automatic dependency resolution or not. Having a command like '/sbin/ifconfig' fail because, for example, 'net-tools' is not installed on those systems, annoys me way more than any lack of auto-dep handling functions on Slackware ever does.

As others have said, it's generally desirable to do a full Slackware install and to keep it in sync. That's when the arguments come in, "Oh, a full Slackware install is so bloated!"

If bloat is an issue, if you omit the KDE, XFCE and (potentially) some other packages groups like emacs, what you're left with is, in my view, a pretty bare system, really. Yes, you have many small tools and daemons available, but by NOT having those tools installed on your system, you're doing so at your own peril in my view. But again, this is just one man's opinion.

From there it's just a matter of common sense. Yes, you need to know a thing or two about your operating system and how library dependencies work in general. Read up on the 'ldd' and 'readelf' commands. But that should be required learning on any Linux system, because if your pretty auto-package-manager fails, you need to know the fundamentals. Tools like sbopkg can help, and there's a nice auto-queue builder called 'sqg' that's located in /usr/doc/sbopkg-*/contrib/ if you have sbopkg installed.

1 members found this post helpful.

This all brings up a very good point, which I think has led me to the point of really paring down my toolset in Linux or BSD, to the point that I use mostly cli tools for most tasks.

After starting out in Linux being enamored with the major desktop environments, watching them "bloat up" over the years, and seeking out gradually "leaner" alternatives, I have come to the point where knowing the "dependency overhead" is key to my decision-making process as to whether I want to install something or not. If the "cost" is too high, I will seek out alternatives, or become more proficient with coreutils (such as with file management).

As it is now, the only reason I have gtk libraries at all is just for a full-featured browser (back to Firefox after 2 weeks with Chromium). I have no qt libraries. I have used Slackware long enough now, and done enough installations, that I always do a custom installation, picking out only the packages that I want. I have learned by trial and error what can stay and what can go for the system I am building. I wouldn't recommend it to a new user, but eventually you come to "get it" when you use something like Slackware, that doesn't just blindly resolve dependencies.