Josh Sled wrote:
Dan Clough <[email protected]> writes:
Even for desktop usage, like I use Slackware, the dep checking has never been
a big deal. It's not difficult to manage, once you know what you're doing,
and it really isn't as hard as some folks think...
In my experience with gnucash (as of a couple of years ago, granted),
9/10 people who had problems building were using Slackware, to a point
where I (and a couple of others) just stopped trying to help them. It
was a waste of our time to do it over and over again, when every other
distro could just do the heavy lifting once.
Dependency management is *inherently* difficult, tedious and error
prone. It's a job well suited for software to help with, but at the
same time requires the careful and qualitative assistance of humans …
package maintainers, specifically, to weigh the requirements and assure
the quality of various versions of packages and how they relate to each
other. More over, those maintainers can encode that knowledge into
packaging scripts, and distribute it to others.
Slack did not have this basic capability for too long, and while
Slackbuilds help, they still don't formally encode even basic dependency
information. In the mean time, Gentoo and Arch have developed mature
systems for handling much of this. I strongly encourage Slackware users
to check them out, and upgrade. :) You'll still have an
as-lean-as-you-want, hand-built, well controlled system … but you'll
save a lot of time getting there, and keeping it up to date.
For example. Yesterday, I did my weekly (Gentoo) system upgrade. Of
the 40 packages that had an upgrade, firefox-3.5.1 needed a version of
xulrunner (1.9.1.1) incompatible with swt-3.4 (a dependency of
vuze-4.2.0.2), which required xulrunner-1.9.0(.11). This was all
presented to me with detail before I even started fetching or building
packages. In this case, swt-3.5 and vuze-4.2.0.4 were both in
"unstable", so I was able to get to solution quickly.
After upgrading all the packages, a quick reverse-dependency scan
revealed two of the other upgrades (dev-libs/icu-4.0.1 -> 4.2 and
media-libs/faad2-2.6.1 -> 2.7) broke a couple of packages each; a
handful of rebuilds later, and the system was linking consistently …
without me running into that problem days/weeks/whatever later when I
went to use the apps and they wouldn't have started for strange reasons.
For completeness: after that, I used a tool to merge my local edits to
the configuration-protected file /etc/mpd.conf as mpd was upgraded.
Then, I checked the list of security advisories, which listed a
half-dozen for the last week, but showed that I was unaffected based on
the versions installed. Then, I got a list of all packages left on the
system that were no longer required by other asked-for/installed
packages, and thus I can clean off of my system, keeping it cruft free.
Note that I spent about 15 minutes actually interacting with all this …
while it certainly takes time to compile stuff, all of that fetching,
configuring, patching, compiling and installing just happened in the
background while I worked.
AFAICT, Slackware simply doesn't have these features. And I don't know
how one can get by without them for any non-trivial modern system.
You have some good points here. Slackware indeed does not have these
features. What you are overlooking, however, is the "Slacker" approach
to this situation. In a nutshell, the approach means that there is
*usually* no need to upgrade 40 packages at a pop. The old saying of
"if it ain't broke, don't fix it", in other words. I have never had any
serious dependency problems in many years of running Slackware.
The way I do things is: With every new release of Slackware, I do a
complete, clean installation of the new version, and then restore my
custom settings, home dir, etcetera... I then install/upgrade
applications that I feel worthy of the time, using Slackbuilds.org
scripts and source. At that time, the only "upgrades" I will do until
the next release of Slackware are those applications already done (with
Slackbuilds), and security updates (easy to track by subscribing to the
official mailing list which notifies me of them). There could also be
(rarely) specific packages that I might upgrade because of a feature
addition that I feel strongly about wanting, and those might have some
new dep's that need solving, but most likely they will not.
The urge to have the absolute latest version of every single software
package out there is something that must be resisted, but with some
practice, it's easy. Another reason that I prefer Slackware is that all
the packages are unaltered and are the original as intended by the
auther of the software. No re-branding, customizing, bastardizing,
breaking, altering, "improving", etc. This includes the kernel.
Strictly vanilla. That may sound boring, but what it provides is
something quite valuable. Things "just work". That's the Slackware
way. YMMV.
