Salix is pretty close to Slackware, I don't know for Vector. From what I have read on this forum, many Slackware users sometimes install Salix for different purposes, because it can be pretty convenient if you don't want to bother with the system.
But anyways, Slackware is (besides LFS) the only distribution amongst the 600+ others that does not have DR. And that is a good thing. Most Slackers prefer it this way, for many it is one of the main reasons to use Slackware. It is very doubtable that this will ever change, so I doubt that bringing up this topic is of no use. I don't want to drive you away, I just question the reason to use a system you are not really happy with if there are viable alternatives.

The sentence "But every now and then I do wonder whether my time could be more productively used working rather than configuring." does imply that, yes.

I use ffmpeg to convert media-files, which has a similar amount of dependencies. Not really hard to compile it, I don't have to do it every month or so, although I am using -current.

There are no major changes in a released version, only in -current, but if you use -current you can hardly complain about changes.
Strange. The software on my systems doesn't break when a new version is released. Unless I try to install the new version. Why don't you just leave the software in its current state and compile the new version when you have the time and mood to do so?

1 members found this post helpful.

Thanks all for the replies, several things are now a bit more clear. As to the 'here we go again' sort of remark, it isn't easy to find much comment on this issue at the 'philosophical' level, so thanks for your patience.

Firstly, I get it that as a complete package, Slackware tends to have 'everything' already included, so the need to add packages (and worry about dependencies) is not as immediate as it is with, say, Arch, where you have to build the whole thing from scratch. I also quite agree that DR sometimes goes wrong--this has happened to me a few times with Mint and, yes, when one is relying on automatic DR, manual fixes are harder to perform. (Once my automatic updater got it into its head that I needed 1177 new packages, and the end result was a total shambles.) But it has always seemed to me that we shouldn't have to choose automation over absolute control--even synaptic gives you the option of accepting or rejecting various stuff. Whatever DR/package manager might be wished for, it should still know how to step out of the way and let you do it the old-fashioned way if you want to. Which is to say that just because some DR systems have issues, it does not follow that DR is itself and inherently bad idea.

As to 'man-hours' and such arguments, I'd say that there seems to be a culture of acceptance of sloppy work here, and maybe some fog about where the responsibility for a decent package lies. I hafta agree with vdemuth's comment. If some app tells me that it depends of something, one would hope that one could believe the developers. If something listed as a dependency is really just an option, its great that I can choose not to install it, but in the real world it bugs me that I should have to worry about such things, and in practice how am I supposed to know what I 'really' need and what I don't? If packages are made, not by the developers of apps, but by the maintainers of distros (I don't even know which it is), then I'd hope that my distro is well made enough that whatever packages there are are properly put together so that installation is painless. IOW, I'd use that distro because the devs spent the man-hours to save the whole user community the man-hours of doing it all individually--that's customer service! Of course, what matters is how things work out in practice. The whole point of computers is automation, that's what they do, but if where the rubber hits the road, DR causes more problems than it solves, then I 'spose we're better without it, but 99% of my use of Synaptic has been absolutely trouble free and it's hard to imagine how it could be better (excepting those disasters, of course ;-) There is a lot of sofware out there that I'd like to try out, and with Synaptic, I can, install, test for a while, and then uninstall quite painlessly, and I'd like to be able to do that with Slack.

Pat sez that time spent sorting out dependencies is time that could be spent fixing other bugs, and of course that's true, but it begs the obvious question, which is, which bugs/issues are of most concern to users? Of course it's far to early for me to make any judgements on that, but it does seem to me that if there is one single reason mentioned over and over again as to why people move away from Slackware, it's the package management/DR issue. Heck, distro's like Salix seem to exist almost for no better reason than to offer Slack + DR, near as I can 'figger. Not that Pat has ever been one to jump on bandwagons, and thank God for that, still it's worth talking about.

One more thing: Yes, if I don't like it I don't have to use it, but that sort of remark suggests that Slack (or anything else who's users make that sort of remark) is no longer interested in being the best it can be and no longer interested in improving itself. And I'm sure that that is not correct.

I'll try Slack when I get the time, and then make up my own mind ;-)

Unfortunately opinions differ about what is "the best". That's exactly why there are several distributions.

IMHO that is the best thing to do. You could even have begun with that.

2 members found this post helpful.

...

Ooops, didn't notice 'page two'. This issue, tho old, still seems to be worth talking about.

I disagree with 55020 who says that worrying about dependencies is 'pathetic'. Any user below expert level should not have to look at error msgs and just know that they can be ignored, that just ain't fair. Nope, packages should be put together well enough that what is marked as needed is infact needed, if it can be omitted, then that too should be clearly noted. Also, Slackware is not exactly light weight, is it? If some library is installed that is not absolutely required, how much fatter does that make one's system in practice?

But there is wisdom in Bazzaah's comment, this is persuasive. Nothing recommends one distro over another more than someone who has used both. Ditto a few others.

chess

Honestly, after reading similar discussions for years regarding dependency resolution and how Slackware does things, I sort of feel like "either you get it, or you don't."

Some folks may have been born 'getting it', but most of us have to learn things. Me, I'm hoping to 'get it' and thanks to some of the comments here, I'm getting closer.


Quote:
I'll try Slack when I get the time, and then make up my own mind ;-)
IMHO that is the best thing to do. You could even have begun with that.

I could have, but before I try something, I like to hear from existing users, so that I can get an idea what to expect, and what the attitude of the thing is. One of the things I greatly admire about Arch is how absolutely up front they are about who they are, and what they are doing--you know exactly what you are getting into. What I get from this discussion is that Slackers are a very conservative group, who are, in the main, not interested in change. Mind, there's too much bloody change out there, right now IMHO, so the Slack attitude might be a welcome refuge for me, right now. Sheesh, there are times when I wish I was still running DOS ;-)

Thanks all.

1 members found this post helpful.

For a system you have to say that Slackware does make you administrate your system more than others down to a point.

In my opinion, as a learning experience, Slackware is the best for educational and introductory purposes. Not only do you have to learn more about how Linux is administrated down at the core functions, but it forces you to learn manual resolutions of problems, especially dependencies.

As far as practicality, it's a weighted game. While other dependency resolving and managed systems are more practical for the average user, after you understand Slackware, know how it functions, and understand how much control you the administrator have, it's almost second nature to work with Slackware just as you would with a distribution like Gentoo, Debian, or even Arch.

@TobiSGD Salix is Slackware but with package management and dependency resolution added in. Otherwise, it's the same exact operating system.

I used Slackware exclusively for around 6 to 9 months, and can share my experience.

I consider myself a fairly typical Linux user. Probably more knowledgeable, and definitely more inquisitive, than average with computers.

It is a good system. It does as intended and advertised. The design is simple, straight-forward, and transparent. As a plus, the forum community is sharp and always willing to help even the most clueless of n00bs.

I do a little web & database development when time permits, but lots of other non-server stuff too. I'm good at figuring out problems to an extent.

But Slackware wasn't a good fit for me because -
--- The 'stable' branch packages get dated, particularly things like KDE. I don't need the latest of everything, but since KDE releases monthly and 13.37 is now almost 1.5 yrs old, do the math. KDE 4.5.5 seems ancient by now. But Alien Bob builds binaries for KDE compatible with current as of 4.7.4, so off to -current...
--- Current worked great for a while, no unstable behavior. But with the major GCC changes a lot of builds starting failing. I don't program in C++ and don't usually jack with include headers to resolve build errors. Could I have learned? Yeah, but is it worth it just to install some updates? My answer is 'no.'

After numerous build errors on simple applications, I went back to Fedora KDE. And damn, I forgot how nice it was to just 'yum install' when I want something like Cairo Dock. Instead of ping-ponging around for various (mostly gnome) libraries and praying for a successful build, I can just install and move on.

Unless your system is a complete POS, a small amount of "bloat" from optional deps isn't going to cause any major problems. At least not enough for me to even notice it.

Bottom line - if you don't want to get down into the depths of knowing how to split a package from its "optional" deps, use something else. That's not a knock on Slackware, it's just the way it is.

Slackbuilds does pose it's own problems because it's a community based supplemental package build-script repository, but you have to realize that each set of SlackBuilds is focused on the stable releases only and the versions of those packages are updated only as the stable releases often are released, unless updates are made for specific reasons.

As of current, there is no rolling release repository that stays completely up-to-date with packages and build-scripts... yet.

rayandrews, do consider the possibility that your opinion may change after you try Slackware and see that taking care of the dependencies isn't as tedious as it sounds. A stock Slackware install already includes most of the dependencies that you'll ever need. For those packages where this isn't true, there are usually SBoPkg queues.

To install kdenlive and all its dependencies actually takes only one command:

2 members found this post helpful.

dugan,

Understand that I'm being a bit of a Devil's Advocate here, but I wanted to hear how people would respond to this issue. I'm very much drawn to doing things in the most direct way and as many have said, Slack's package management works better than its reputation would suggest. I just don't want things to be pointlessly difficult, that's all. At the same time, it seems a shame for the most stable of all distros to loose userbase because of something like DR.

BTW, just in passing, one thing that draws me to Slack for sure is that it still uses LILO. What a relief it was when I got rid of GRUB here. FWIW, GRUB seems to this cowboy to be almost the ultimate example of bloated, impenetrable software. Badly designed, badly documented, badly coded. Bad to the bone.

GRUB is very vague in it's layouts of disks and partitions. It can be easy to work with when you find the right guide or a total pain in the butt.

LILO often can have it's problems too, but usually those are few.

Using Mandriva and Ubuntu I occasionally had broken packages, where package A depended on package B, but package B had been upgraded or something, breaking package A.... NOW WHAT? Or even worse (and more common) I wanted to install Package A which depended on Package B which depended on packages C and D which depended on............ it was like if you've ever turned a video camera on it's own monitor. It drove me nuts.

It's not that software doesn't necessarily have the same dependencies when I'm using Slackware, it's that with a full install by default most of those dependencies are resolved before I've even entered my root password. I understand the bloat argument, but honestly 4 or 6 GB (or whatever we're currently at) for a total install is really pretty minimal... for me at least, I think my $200 laptop has a 300GB HD. Building packages can be a pain, but for the most part it really isn't a big deal. Working from a full install as my starting point, and using sbopkg to handle the build and install process, I very rarely go over 5 packages needed for a particular piece of software and on my hardware at least it doesn't take me any more time to download and build 5 packages than it does to download and install the 15 or however many with other distros that I've used. And that's the part that just drives me up a wall - by doing a minimal base install, it really just dooms me to download dependencies EVERY TIME I add a package, unlike Slackware where 5 is generally the max and none is very common. There are some packages like VLC, and ffmpeg that I download from trusted sources like Alien BOB to add functionality, and there are several stock Slackware packages that I rebuild to take advantage of some installed dependency of my own. The only time I really have issues is running current and then trying to build packages, sometimes I'm forced to hunt down my own patches, or update versions of upstream tar-balls, but over time even that has become less of an issue or it's just become easier, or it's something I do when I just can't sleep anyway! LOL

In my personal opinion dependency resolution is HIGHLY overrated, or at least it being a mark against Slackware is highly overrated, but that's really what I like about Slackware in the first place, Slackware is just Slackware, either you appreciate it's particular way of doing things or you don't. The choice is ultimately up to the user, like everything else in Slackware.

I think I just learned something......that's what I get for not reading the documentation, does the -i switch cause sbopkg to look at the dependencies and attempt to download, build and install them for me? I did a test run and that's what seems to have just happened. I think I'm about to be an even happier slacker

No, sbopkg does not do any dependency checking for you. The -i switch installs the package you are building. But sbopkg has the "queuefile" feature where you can save the correct order of dependencies and sbopkg will build and install everything in the right order from your list. But determining the dependency order is still left to the user.

http://sbopkg.org/queues.php

There are several places with user-contributed queuefiles. http://slackermedia.info/downloads.html is one place with multimedia-type queuefiles. I think ponce also has a repo of queuefiles IIRC.

2 members found this post helpful.

To clarify even further, there's a large repository of prebuilt queuefiles. This repository includes a queuefile to build kdenlive. When you launch sbopkg with -i kdenlive, it will detect whether you have a queuefile for kdenlive. If you do, it will ask whether you want to build the package, or the entire queue.

It gets better. The following will build the kdenlive queue and skip packages that are already installed:

2 members found this post helpful.