In the first place they would tell the customer that it is a bad idea to install an untested program in a production environment and that it would be better to test that first.
In the second place, when a customer has the specific wish to use a program it is the admins job to integrate that program in that specific environment, not to simply trust that some random package maintainer has done the job exactly like he needs it.

Don't get me wrong, I am not saying that dependency resolution is always a bad idea. It makes sense in some cases. Slackware is not one of these cases.
If you want dependency resolution you have a couple of choices:
1. Don't use Slackware.
2. Use Slackware with one of the available resolving managers, like slapt-get.
3. Fork Slackware and implement your own package management system with dependency resolution.

All of these approaches, except the last one, have one thing in common for the admin: he is giving the control about which software is installed with which (optional) dependencies (on the machines he is paid for to have the control over) to a third party which lies not in any way in his control.

If it goes right first time. But when package x needs package y & z, which in turn need packages q,m,j and f. Which in turn need packages..... well you get the idea, then your few minutes has the potential to turn into hours. And lifes just to short.

Can't disagree with that. So as I said, anything that makes life easier in the long run must surely be a good thing.




Didn't say it would just be an arbitrary program at the whim of the user, and yes, you are correct of course that the admin would make sure it is integrated correctly, but as the saying goes, especially in business, time is money. And time spent wasted is time never to be reclaimed.

Depends on the viewpoint. having the exact knowledge which software runs on my systems and with which dependencies I have compiled a certain software makes my life easier in the long run, so manual dependency management together with a very simple package format surely must be a good thing.

The client networks I take care of are much smaller than 1000+ PCs. More in the range of 10 to 30 PCs. Until recently I've been using Debian stable for the job. You wouldn't believe it, but a task as simple as replacing the stale Firefox 3.5 by a backported 10.0.x ESR version turned into a nightmare with Debian. Somewhere some package maintainer introduced a new dependency into one single backport, and suddenly I got a tsunami of updated packages and in the end a broken package manager. When asking on Debian IRC, forums and mailing lists, I got either treated as a complete newbie, or otherwise sent a curt pointer to some /etc/apt/preferences file from hell.

This was one of the reasons I decided to switch to Slackware for my client's production desktops. For instance, I wanted to go with Firefox ESR, so I simply took the SlackBuild, changed it a bit to fit Firefox ESR, compiled it twice on my buildbox, once for Slackware and once for Slackware64, and put everything on a server for deployment.

Now installing a desktop is as simple as upgradepkg --reinstall --install-new *.tgz:

http://www.microlinux.fr/slackware/14.0/slackware/i486/

Here's the resulting desktop:

http://www.microlinux.fr/desktop_linux.php

Cheers,

Niki

That's fine, but in the context of the original subject matter of this thread, you would know exactly what was required for each installed package anyway as they would all be installed within their own directory, including all prerequisites.

Even easier than having disparate numerous libs scattered over a drive.

If it ain't broke, don't fix it!

However...

if one wanted to experiment something new, they should do like Chrome OS: whenever a new system upgrade or critical update is available, the OS will load it in the background, user will be alerted that an update is available and prompted to reboot to take effect.

This could be a feature for paying users.

(I know, I've become a Chrome fanboi...)

Were that the case we would still be living in the stone age.:D

I would still not have control over the used dependencies, so that wouldn't change a thing. An admin is paid to have control over the machine, not to give that control to a random package maintainer.

Then I guess it comes down to a matter of trust. Most admins I know quite simply they don't have time to allow themselves the luxury of being able to tailor each machine, or even groups of machines of the same specification, but have to work with the tools they are given.

Probably the reason why the likes of Red Hat are so successful is because their packages can be trusted and their dependency resolution works more often than not, while still allowing admins to retain control.

OK, I agree that when things go wrong, the simplicity of Slackware would seem to allow a more logical way to put things right, but when it comes to installing new programs, even the best admin would no doubt prefer to take 10 minutes rather than 10 hours to complete the task, especially when the outcome is more likely to be a success rather than a failure.

I've been a CentOS 5.x user for a few years, and I remember the PITA it was to install just a minimal GNOME desktop because the package maintainers got some Pidgin dependency wrong, so you had to jump through burning loops to install it anyway, because 'yum groupinstall "GNOME Desktop Environment" would stop dead, so you had to rpm -ivh --force some things first. And it took them more than a year (!) to fix that stupid thing.

Your point being?

I think his point (correct me if I'm wrong kikinovak), is that in situations like the one he gave, dependency resolution does not allow the system to function properly due to the mistake of somebody else that, some system administrators in the world can fix on their own. If a system administrator does know how to fix the problem like the one in kikinovak's example, there would be less time fixing the system, and more time using it. Plus, on a system with a more complex package manager than something like pkgtools, it could get in the system administrator's way of fixing the problem manually if he/she so desired.

There have been many dependency resolving package managers that I have used, where I went "wait...why does it say I need this?" only to see that it built without that dependency (and ran perfectly fine without it) when built from source. Some of them had to be rebuilt because a dependency (that I didn't need or want) became a security vulnerability.

Also, based on your posting history it seems you ignore large posts that (from what I observed) answers your questions, and you keep skipping them for small (or less knowledgeable posts) that you feel you can attack. So please show some respect not in your attitude, but in your posting manner. If you don't read other peoples post, we shouldn't have to read yours, and some of your posts are somewhat ignorant to an extent. Your basic idea seems to be "I like Slackware but I don't like the fact that it doesn't resolve dependencies, and I don't like other distributions because they're not Slackware." Well, not resolving dependencies is one of the things that makes Slackware, Slackware. So either you love Slackware or you don't, and if you don't, there's no need to use it and there are more distributions out there, some of which are derived from an actual Unix OS, so they should also be fairly Unix-like as well.

Is this another try to promote functional programming through the backdoor? ;-) Then I have bad news for you: It won't work. Beside that, while Scheme has its uses, I don't see where it's beneficial for package management.

And that the GNU project is lead by a LISP lover surely is just a coincidence...

Whoa boy, what's with the personal attack.

I read what was put by kikinovak and see his point. But, and bear with me here, lets take his situation. Yes the packaging team at CentOS may not have robustly checked if the quality of the Gnome package but I find it unlikely that for someone who has been using CentOS for 5 years would have allowed it to be a showstopper and even though it may have taken a year for the packagers to fix it, does that mean he was without his OS for 12 months?

If you look at it from a different angle for a minute, how long do you think it would be after issuing a command to install a package set (say Gnome) that you would be informed by the package manager that not all dependencies were met. Now compare that time with how long it could potentially have been had you needed to install the whole lot from source to find issues. Even Pat wont do that with Gnome, which speaks volumes. So which scenario gave him information sooner rather than later, and allowed him to work on a solution rather more quickly?

You know, I have read a lot of threads about dependency resolution and whether it should be included in Slackware or not and it always brings out the worst in the fan boyz, but this thread is not about that anyway if you read from the beginning. It is however asking about peoples thoughts on an alternative packaging and software installation scheme and dependency resolution is simply a side effect of it's proposed utilisation.
I still after all the years I have been using Slackware fail to understand why those using it are so afraid of embracing new ideas.

More like uninterested in embracing irrelevant ideas.