Chess wrote:Tsuroerusu wrote:I don't see the fuss about having a package manager that calculates dependencies.
Just to play Devil's Advocate here...
Package managers that calculate dependencies are not perfect. Apt-get is supposed to be the end-all and be-all of package managers. How many times have all of us heard or read about a Debian user who fubared their system because of an upgrade or something? Sure, if you stick with just stable, then you are ok, but that's the same thing as sticking with initial set of packages of any distro, including Slackware. It's when you go outside that stable repository that you can introduce problems.
OK, I think you just mixed two things together there for a minute Chess.
Most geeks who use Debian as their desktop system, most likely don't use vanilla stable, because it's just so outdated by now in terms of KDE, GNOME and all the bells and whistles, so they either add backports repositories or use either the testing or unstable branches.
Testing and unstable are development branches, stuff that you're not supposed to use on "production" systems, sure a lot of advanced users will argue, myself included at times, that it's fine, but it's not guaranteed in any way.
Also, concerning upgrades, a few days ago I wanted to see if SUSE really was as bad at upgrading as it is in my experience, and what I found was that if I just installed SUSE and just used it the way the distro was supposed to and not tweaking the multimedia support and stuff, not adding some mime type stuff, I could easily do an upgrade it worked perfectly, and I started with 9.1 Personal and upgraded all the way to 10.1 and no problems at all. I'm sure this goes for Ubuntu as well, and after hearing about the issues with upgrading Ubuntu on the tech show I realized something, the distro maintainers just can't take into action, how you tweak your system, and if you use 3rd party repositories that some where in the linkage corner some dependencies up against the wall, you introduce issues, sure Slackware won't bug you about this, but IF something is fubared you need to go dig for the issue yourself, which I find a big pain in the butt.
Something I noticed on SUSE is that because there aren't that many community repositories, most people primarily use two, the guru and packman repositories, there are rarely dependency issues, on Fedora you have some repositories mirroring each other's work so you can't use them together.
Chess wrote:I have Arch on one of my workstations and I love it. Pacman is great. But, I have had breakage. Nothing that I couldn't fix, but still, the package manager that calculated dependencies caused the problem. On my Slackware system I never have dependency problems.
I think Arch is a little bit of a special case, because compared to Debian, how many testers and developers does it have? And because it aims so strictly at experienced users, you also limit the number of people who can report the issues, even if it's just by a margin.
Chess wrote:I'm not saying it's for everyone. And, I'm not saying I don't use apt-get or pacman because I do and it is nice.
Smart has some interesting solutions to dependency issues, there are several ways of locking a package so you can't install or uninstall a package and if you get a dependency issue, you just use the lock feature in the apropiate places and it won't bug you, takes 10 - 30 seconds, for example, recently the Packman guys had a rare screw up, because they accidently made the vlc package depend on a specific version of ffmpeg I believe so you couldn't install vlc and upgrade MPlayer at the same time, so what I did before they issued and update was that I uninstalled VLC, upgraded MPlayer, used YaST to install VLC as it can completely ignore the dependency issues, and then in Smart I locked VLC, and then it didn't bug me at all, took me no time at all to do.
Chess wrote:But, (remember, I'm playing Devil's Advocate, here), the idea of not using a package manager that calculates dependencies is not as crazy at it seems. If you do the dependency checking and compiling yourself, then you really tend to avoid those problems.
Sure, but in my mind you introduce a lot of additional complexity, because you need to go to tools like ldd or stuff like that to figure out what's wrong and increases the amount of time to install larger stuff, like Mono for example, which Dann said is a bitch to install on Slackware
Sure you can fault Miguel and his boys for not sticking with the classic UNIX saying of KiSS, but Mono is really not something you can do simple, especially since to a degree it's derived from some Microsoft designs.
Chess wrote:I don't compile everything, of course, like KDE or GNOME, but for the "extras", compiling yourself tends to reduce problems. It not as easy, and takes longer, but it tends to be more stable in the long run.
Now see, this is where I get confused, what's the difference between this and running Gentoo, because as CptnObvious999 pointed out to me, there are binary packages available for the big apps like KDE and OpenOffice. For example you can get a Gentoo system running relativly quickly with KDE or GNOME, and just compile the extra stuff yourself.
I can also do this with FreeBSD which has a binary package collection of over 14,000 and rapidly closing in on Debian, also it allows you do to stuff like edit the actual dependencies so if there's a naming issue I think you can just correct that, you can certainly just edit the makefile that make up an entry in the BSD Ports system, which is just a hairy-ass Makefile infrastructure.
