LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 11-25-2012, 12:35 PM   #16
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Slackware
Posts: 14,880
Blog Entries: 2

Rep: Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805

Quote:
Originally Posted by vdemuth View Post
Go ask an admin team that has to regularly look after 1000's of PCs every day and see what they would prefer when a customer asks for program A. They can either grab it, complete with all required runtime libs, dependencies et al and install it on the recipients computer, or they can spend the next X hours scouring every corner of the Internet to get all the needed component parts, compiling etc etc ad nauseam.
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.
 
1 members found this post helpful.
Old 11-25-2012, 12:38 PM   #17
vdemuth
Member
 
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),Suse 13.1 (Desktop),, Mepis on the wifes lappy
Posts: 760

Rep: Reputation: 90
Quote:
Originally Posted by GazL View Post
It only takes a couple of minutes to download a build from slackbuilds.org, extract and run it (and that's assuming one doesn't use a helper like sbopkg) so I don't accept your argument that it is time consuming to do this stuff manually. I certainly don't spend that much time downloading and building stuff.
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.

Quote:
Originally Posted by GazL View Post
However my objection is not about the time involved. It's about having to remember the details,syntax and idiosyncrasies of yet another programming language. A long career in IT has resulted in my mind already being far too cluttered with this sort of stuff
Can't disagree with that. So as I said, anything that makes life easier in the long run must surely be a good thing.




Quote:
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.
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.

Last edited by vdemuth; 11-25-2012 at 12:42 PM.
 
Old 11-25-2012, 12:42 PM   #18
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Slackware
Posts: 14,880
Blog Entries: 2

Rep: Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805
Quote:
Originally Posted by vdemuth View Post
So as I said, anything that makes life easier in the long run must surely be a good thing.
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.
 
Old 11-25-2012, 12:48 PM   #19
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, Slackware64
Posts: 1,410

Rep: Reputation: 630Reputation: 630Reputation: 630Reputation: 630Reputation: 630Reputation: 630
Quote:
Originally Posted by vdemuth View Post
Fine for a server environment, but in a large mixed one, where different people have different requirements, different access rights and the need to use different programs, even a system admin needs to be able to get people up and running and keep them that way as quickly as possible.
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
 
3 members found this post helpful.
Old 11-25-2012, 01:02 PM   #20
vdemuth
Member
 
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),Suse 13.1 (Desktop),, Mepis on the wifes lappy
Posts: 760

Rep: Reputation: 90
Quote:
Originally Posted by TobiSGD View Post
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.
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.
 
Old 11-25-2012, 01:05 PM   #21
ottavio
Member
 
Registered: Nov 2007
Posts: 312

Rep: Reputation: 46
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...)

Last edited by ottavio; 11-25-2012 at 01:16 PM.
 
1 members found this post helpful.
Old 11-25-2012, 01:22 PM   #22
vdemuth
Member
 
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),Suse 13.1 (Desktop),, Mepis on the wifes lappy
Posts: 760

Rep: Reputation: 90
Quote:
Originally Posted by ottavio View Post
If it ain't broke, don't fix it!
)
Were that the case we would still be living in the stone age.
 
Old 11-25-2012, 01:35 PM   #23
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Slackware
Posts: 14,880
Blog Entries: 2

Rep: Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805
Quote:
Originally Posted by vdemuth View Post
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.
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.
 
Old 11-25-2012, 02:06 PM   #24
vdemuth
Member
 
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),Suse 13.1 (Desktop),, Mepis on the wifes lappy
Posts: 760

Rep: Reputation: 90
Quote:
Originally Posted by TobiSGD View Post
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.
 
Old 11-25-2012, 04:09 PM   #25
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, Slackware64
Posts: 1,410

Rep: Reputation: 630Reputation: 630Reputation: 630Reputation: 630Reputation: 630Reputation: 630
Quote:
Originally Posted by vdemuth View Post
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.
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.
 
Old 11-26-2012, 12:27 AM   #26
vdemuth
Member
 
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),Suse 13.1 (Desktop),, Mepis on the wifes lappy
Posts: 760

Rep: Reputation: 90
Quote:
Originally Posted by kikinovak View Post
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?
 
Old 11-26-2012, 01:19 AM   #27
TommyC7
Member
 
Registered: Mar 2012
Distribution: Slackware, CentOS, OpenBSD, FreeBSD
Posts: 419

Rep: Reputation: Disabled
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.
 
Old 11-26-2012, 08:29 AM   #28
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 690

Rep: Reputation: 276Reputation: 276Reputation: 276
Quote:
Originally Posted by DrCube View Post
If you're worried about control, it uses Guile Scheme so it's extendable and hackable.
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...

Last edited by jtsn; 11-26-2012 at 08:42 AM. Reason: spelling
 
1 members found this post helpful.
Old 11-26-2012, 10:30 AM   #29
vdemuth
Member
 
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),Suse 13.1 (Desktop),, Mepis on the wifes lappy
Posts: 760

Rep: Reputation: 90
Quote:
Originally Posted by TommyC7 View Post
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.
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.

Last edited by vdemuth; 11-26-2012 at 10:31 AM.
 
Old 11-26-2012, 11:04 AM   #30
mudangel
Member
 
Registered: May 2008
Location: Ohio
Distribution: Slackware
Posts: 267

Rep: Reputation: 48
Quote:
Originally Posted by vdemuth
afraid of embracing new ideas.
More like uninterested in embracing irrelevant ideas.
 
4 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Question] User based Package Manager... RaptorX Linux From Scratch 0 07-23-2009 01:07 PM
GUI based package-manager installation on console based linux kevinchkin Linux - Software 2 07-14-2009 12:25 AM
Questions related to package manager based and manual installation koobi Red Hat 3 11-05-2007 06:46 AM
Menu based console package manager? nebdy Linux - Software 1 06-28-2004 06:07 AM


All times are GMT -5. The time now is 11:17 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration