LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
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
 
Search this Thread
Old 02-17-2011, 09:07 AM   #1081
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: SlackwareŽ
Posts: 11,396
Blog Entries: 3

Rep: Reputation: 1482Reputation: 1482Reputation: 1482Reputation: 1482Reputation: 1482Reputation: 1482Reputation: 1482Reputation: 1482Reputation: 1482Reputation: 1482

Hi,

Quote:
Originally Posted by AGer View Post
Wanting somebody else to do finger pointing and name calling on behalf of Slackware?
No, you fail to see that it is not a Gnu/Linux specific problem. It's application(s) that are used on all distributions. Why should we setup things at the level that should be handled upstream. Maintenance alone would be a big issue.

Quote:
Originally Posted by AGer View Post
I agree this is not an OS issue because the OS is Linux. This is a distribution issue, so it is a legitimate request. I guess the proper answer should be "Sorry, this goes against Slackware design principles. Please switch to some other distribution built around support for insane ideas of corporate execs.
It is not a distribution specific problem when it is across all distributions. I don't see how it would be against the Slackware design criteria or principles. You could be specific if it is something else that I am not aware of.

As to the statement by switching to another distribution that has solved this issue (when non exist) is an absurd statement. If the known problem is across all or most Gnu/Linux then which distribution is your inferences based? Problems is, standards are not being followed or adhered to thus the blame to the upstream developer(s).

Quote:
Originally Posted by AGer View Post
Alternatively, since the same goals may be also acheived in a distribution agnostic way on a file system or application levels, you may want to initiate an appropriate project on Source Forge".
Both clear abd polite, isn't it?
Simplistic at most. Why don't you start the project and put the wheel in place to solve a problem that is Gnu/Linux wide? Big project!
 
Old 02-18-2011, 02:48 AM   #1082
stoggy
Member
 
Registered: Jun 2008
Location: Dallas, TX
Distribution: Slackware and FC
Posts: 107

Rep: Reputation: 20
The finger pointing is already done. You will have to read up its pretty old.

http://www.linuxfoundation.org/colla...workgroups/lsb


Quote:
It is not a distribution specific problem when it is across all distributions. I don't see how it would be against the Slackware design criteria or principles. You could be specific if it is something else that I am not aware of.
WTF? the kernel has bugs too, why do they get fixed too then.

Last edited by stoggy; 02-18-2011 at 02:51 AM.
 
0 members found this post helpful.
Old 02-18-2011, 02:55 AM   #1083
mudangel
Member
 
Registered: May 2008
Location: Ohio
Distribution: Slackware
Posts: 267

Rep: Reputation: 48
Quote:
Originally Posted by stoggy View Post
WTF? the kernel has bugs too, why do they get fixed too then.
And your point? Kernel maintainers fix kernel bugs, right? What does this have to do with Slackware?
 
Old 02-18-2011, 03:05 AM   #1084
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,293

Rep: Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712
Quote:
Originally Posted by stoggy View Post
The finger pointing is already done. You will have to read up its pretty old.

http://www.linuxfoundation.org/colla...workgroups/lsb



WTF? the kernel has bugs too, why do they get fixed too then.
What are you talking about? LSB is about ensuring some level of compatibility when applying one set of binaries from one distro to another -- there should be a certain similarity (LSB-compliance) that allows the same binaries to work on both platforms (ignoring any issues with dynamic compilation). It requires that certain packages be shipped with the distro that can be used in reliable ways so that it is easier for packages to be transferable from distro to distro (to avoid the problem of a distro not being able to support a given package). This has *NOTHING* to do with your complaint at all and I have no idea why you brought it up.

The kernel gets fixed because it is shipped as one piece of integrated code. It must all work together and be configurable via the same interface. What you are asking is for every application on Linux to share a standardized user-based configuration format. Possibly a good idea, but it is *impossible* to patch every single piece of software that ships with Slackware (or *any* distro) to support such a scheme. You would have to introduce a configuration-based standard that gets adopted by the majority of upstream application developers so that all distros have a common user configuration method, and would only have to patch the occasional piece of software to support such a scheme (assuming they have a patching philosophy). What you are asking is for distro maintainers to modify nearly every piece of user-configurable software on the system to define specific config locations. This is *ALWAYS* a bad idea -- people with much less experience than the original application developer(s) patching code when they may not know the side effects, having to do that for hundreds of packages. There will be problems with that approach.

This is not a bug with Slackware (or any distro) -- this is a bug (if you want to call it that) in GNU/Linux as a whole for not setting user configuration standards and a result of disparate upstream developers working on significantly different applications that choose differing configuration schemes. Whenever you find an application that does not use your definition of the appropriate configuration scheme, you should contact them and request that they change it (though I cannot imagine that correspondence would be well received).

You may want to look into gconf if you want a unified configuration utility. Perhaps this is not used widely enough to move to an exclusively gconf-based configuration; additionally gconf does not necessarily support the same kind of configuration that individual applications do.

[edit]As to your original problem, it may be wise to keep application versions synchronized if you are going to share your home directory across computers...[/edit]

Last edited by T3slider; 02-18-2011 at 03:08 AM.
 
Old 02-18-2011, 03:59 AM   #1085
AGer
Member
 
Registered: Oct 2007
Distribution: Slackware current
Posts: 136
Blog Entries: 22

Rep: Reputation: 19
Quote:
Originally Posted by onebuck View Post
No, you fail to see that it is not a Gnu/Linux specific problem. It's application(s) that are used on all distributions. Why should we setup things at the level that should be handled upstream. Maintenance alone would be a big issue.
In general, upstream developers do whatever they want and it is absurd to think that something "should be handled upstream". There are nearly no ways to influence upstream development if your problem is not a bug that they are willing to acknowledge.

For example, mplayer developers do not want to move the code that allows to play linked video from a branch to the trunk. Having problems with linked video, should people think that something "should be handled upstream"? No, the system just does not work that way. Put differently, they may think whatever they want with exactly zero gain.

Another example. The MRI code that deals with file searching and reading on Windows is insane. All that can be done here is to fix that, propose changes, and hope they will be accepted (as the Ruby Installer people actually do). This is Ruby, so there is no chance the developers are bad, incompetent, lazy, or imperfect in any way. This is just how the system works.

In particular, most developers assume that their program is updated from time to time and the newer version should use the user settings from the older one. Even that is not provided way often, like with KDE updates.

Quote:
Originally Posted by onebuck View Post
It is not a distribution specific problem when it is across all distributions. I don't see how it would be against the Slackware design criteria or principles. You could be specific if it is something else that I am not aware of.
No, it is a distribution specific problem because such things are handled on the distribution level. For example, most of the distributions put executable files into bin and friends, while some create a separate directory for each application.

Currently most distributions just do not care where the .files are placed and if you look into a home directory you will see that different developers have different ideas and the result is a mess.

One of the Slackware design principles is to interfere with the upstream as little as possible. So, no tricks with the home directory here.

Quote:
Originally Posted by onebuck View Post
As to the statement by switching to another distribution that has solved this issue (when non exist) is an absurd statement. If the known problem is across all or most Gnu/Linux then which distribution is your inferences based? Problems is, standards are not being followed or adhered to thus the blame to the upstream developer(s).
Yes, standards are not being followed, period. They have some influences that justify their existence and this is all that can be achieved. All browsers behave differently, right?

I am not sure that ALL distributions have that problem. There are hundreds or thousands of them.

I doubt most of the distributions see a problem here. Thus, it is not a "known problem", it is YOUR problem. To fix it you may want to find people who have the same problem and cooperate solving it. You may decide to create a distribution to do that. Thus, the first step is to look if one already exists. It is not Slackware for sure.

Quote:
Originally Posted by onebuck View Post
Simplistic at most. Why don't you start the project and put the wheel in place to solve a problem that is Gnu/Linux wide? Big project!
I do not have that problem. I also think very few do have it since what you ask for is neither "a machine is set up how its users see fit", which is normal for Linux users, nor "I can go anywhere and get exactly the same environment", which may be expected in a cubicle farm environment.

If you do not mind a crash when 2 people log in as the same user on 2 machines simultaneously and are willing to make the same changes to application settings again for each application version, there must be some quick hacks for your environment.

If you want a generic solution, I guess that should be something on a file system level. Not really big, but complex.

Last edited by AGer; 02-18-2011 at 04:03 AM.
 
Old 02-18-2011, 12:32 PM   #1086
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,293

Rep: Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712
Quote:
Originally Posted by AGer View Post
In general, upstream developers do whatever they want and it is absurd to think that something "should be handled upstream". There are nearly no ways to influence upstream development if your problem is not a bug that they are willing to acknowledge.

...

No, it is a distribution specific problem because such things are handled on the distribution level. For example, most of the distributions put executable files into bin and friends, while some create a separate directory for each application.
I still maintain that this is not a distro's job. If you want to run multiple instances of KDE using disparate versions you can always set KDEHOME and be happy. Upstream developers should be encouraged to add an option to dictate which configuration file/directory to use. GNU screen has the -c option, mutt has -F, Firefox has the ability to use multiple profiles, etc. Then in a .bashrc you could set aliases depending on the computer's hostname. Of course a unified solution would be beneficial but it isn't practical to expect a distro to patch every package without introducing errors and create immense amounts of extra work that would take away from other duties. If there is a software package that does not allow config file specification then bug them to add it. It's already available in most software anyway.
 
Old 02-18-2011, 01:00 PM   #1087
Robert.Thompson
Member
 
Registered: Nov 2009
Location: Montreal, Quebec, Canada
Distribution: Slackware 13.37 -32 Bit
Posts: 578

Rep: Reputation: 49
The option to automatically check for and install dependencies.
 
Old 02-18-2011, 01:12 PM   #1088
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,244

Rep: Reputation: 573Reputation: 573Reputation: 573Reputation: 573Reputation: 573Reputation: 573
Smile

Quote:
Originally Posted by Robert.Thompson View Post
The option to automatically check for and install dependencies.
Well, I must respectfully disagree with you on that point. I see the absence of dependency checking as a strength rather than a deficit. As the administrator of my Slackware boxes *I* am the dependency checker for my systems.
 
5 members found this post helpful.
Old 02-18-2011, 01:49 PM   #1089
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,293

Rep: Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712
Quote:
Originally Posted by Robert.Thompson View Post
The option to automatically check for and install dependencies.
I think Slackware presents a unique situation here. By default Slackware expects a full install, so there really are no dependencies to check. If you were to request that the unofficial slackbuilds.org would provide dependency information in a standardized format (separating optional and required dependencies into two lists) so that sbopkg could parse that information and automatically build queues (allowing you to select/deselect optional dependencies)...well, then I may support you. However, providing dependency information for core Slackware packages is a moot point in my opinion since anyone who is not capable of determining properly which packages they need should probably be running a full install anyway.
 
3 members found this post helpful.
Old 02-18-2011, 02:48 PM   #1090
sycamorex
LQ Veteran
 
Registered: Nov 2005
Location: London
Distribution: Slackware64-current
Posts: 5,581
Blog Entries: 1

Rep: Reputation: 1033Reputation: 1033Reputation: 1033Reputation: 1033Reputation: 1033Reputation: 1033Reputation: 1033Reputation: 1033
Quote:
Originally Posted by hitest View Post
Well, I must respectfully disagree with you on that point. I see the absence of dependency checking as a strength rather than a deficit. As the administrator of my Slackware boxes *I* am the dependency checker for my systems.
While I totally agree with you and do NOT see the need for automatic dependency checking I think Robert highlighted the word 'option' for a reason. Perhaps, some weird people would like such capability. On the one hand, such an OPTION would let Slackware accommodate the needs of a wider range of users, on the other hand, it'd create an unnecessary layer of complexity, which we don't like, do we?

What I'd like in future releases of Slackware is the inclusion of:
rtorrent, inkscape, tmux and i3.
I know inkscape has quite a few dependencies from outside of stock slackware so I understand why it's not going to be part of the full install any time soon (if ever), but including tmux and rtorrent would save me 2 minutes from my life each time I configure slackware, LOL.

Last edited by sycamorex; 02-18-2011 at 02:50 PM.
 
Old 02-18-2011, 03:28 PM   #1091
Robert.Thompson
Member
 
Registered: Nov 2009
Location: Montreal, Quebec, Canada
Distribution: Slackware 13.37 -32 Bit
Posts: 578

Rep: Reputation: 49
Quote:
Originally Posted by T3slider View Post
... request that the unofficial slackbuilds.org would provide dependency information in a standardized format (separating optional and required dependencies into two lists) so that sbopkg could parse that information and automatically build queues (allowing you to select/deselect optional dependencies)...
"What you said!"

Being very honest, when I install a SlackBuild, I have no idea if the dependencies are good, bad or whatever so, I just install them anyway. I read the dependency descriptions, but have no idea what the significance of most of them are any way.

I guess I'm just a lowly "Slackware dilettante".
 
Old 02-18-2011, 04:03 PM   #1092
AlvaroG
Member
 
Registered: Jul 2009
Location: Canelones, Uruguay
Distribution: Slackware
Posts: 128

Rep: Reputation: 31
Well, there is one thing that noone can deny: if you are sure you are going to install package A, and it depends on B, you will end up installing B! So while I don't think the automated and mandatory dependency checking is a good idea (having suffered with it with Fedora and Mandriva), I do support the idea of having SlackBuilds with dependency information. After all, if it is job that one will do anyway, why don't let machines do a suggestion of extra packages to install?
 
Old 02-18-2011, 04:14 PM   #1093
zbreaker
Member
 
Registered: Dec 2008
Location: New York
Distribution: Slack -current, #!, vsido
Posts: 225

Rep: Reputation: 27
I have no reason to fear any dependency indicated at SlackBuilds.org. One has just to look at the names of the "maintainer" and "approver" to have total confidence. Also we have a couple of well known folks who have rather nice collections of SlackBuilds and packages for your dining & dancing pleasure.
 
Old 02-18-2011, 04:33 PM   #1094
mudangel
Member
 
Registered: May 2008
Location: Ohio
Distribution: Slackware
Posts: 267

Rep: Reputation: 48
Quote:
Originally Posted by AlvaroG View Post
Well, there is one thing that noone can deny: if you are sure you are going to install package A, and it depends on B, you will end up installing B! So while I don't think the automated and mandatory dependency checking is a good idea (having suffered with it with Fedora and Mandriva), I do support the idea of having SlackBuilds with dependency information. After all, if it is job that one will do anyway, why don't let machines do a suggestion of extra packages to install?
How about this?
 
Old 02-18-2011, 08:43 PM   #1095
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 420
Blog Entries: 4

Rep: Reputation: 426Reputation: 426Reputation: 426Reputation: 426Reputation: 426
Quote:
Originally Posted by Robert.Thompson View Post
The option to automatically check for and install dependencies.
Bad idea. Everything that is optional for the *user*, is compulsory for the *maintainer*.

Why do Slackpeople tend to dislike dependency checking? Because of three reasons, IMO. (1) Its complexity makes maintenance more difficult. (2) Consequently, it is buggy. (3) And consequently, it is inflexible, because to make it more flexible would need even more complexity, and thus even more maintenance and even more bugs.

In more detail:

(1) I maintain quite a few packages at SlackBuilds.org, and so I watch what maintenance other distributions perform on "my" packages (bug reports, patches). I guess at least 50% of the changesets I see elsewhere relate to dependency checking. What a colossal waste of effort! But, Robert, to give you the *option* of dependency checking, I would *have* to do all this extra work.

(2) And, because nobody is perfect, extra work for *me* means extra bugs for *you*. And *fixing* those extra bugs is yet more work for *me*.

(3) And as for the inflexibility, please let me quote AlvaroG who was wrong when he said:
Quote:
Well, there is one thing that noone can deny: if you are sure you are going to install package A, and it depends on B, you will end up installing B!
Dependency is not all-or-nothing. Packages generally contain lots of components, and each component has an independent set of dependencies. If a package contains both command line tools and graphical tools, well, on Slackware I can install (for example) d/git-1.7.1-x86_64-1.txz onto a headless system without X and TK, and, so long as I don't try to run gitk, everything is just fine. It's not a problem to have unfulfilled dependencies of stuff you will never run! Of course, other distributions sometimes split upstream packages for this reason, but that brings even more complexity, maintenance overheads and bugs.

All this, ladies and gentlemen, is why there should be at least *one* distribution that does *not* have dependency checking. The name of that distribution happens to be Slackware. If you are daft enough to want dependency checking, well, hey, you have plenty of choices of other distributions. But adding dependency checking to Slackware -- even optional-in-red dependency checking -- reduces *my* choices from one to zero. NO!!!

What on earth is it that offends the dependency addicts so much that they keep wanting to eliminate our dissent? Are they jealous of our productivity, stability and flexibility? Is that it?
 
27 members found this post helpful.
  


Reply

Tags
cd, live


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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware future? coyctecm Slackware 12 02-01-2006 11:03 PM
Future of Slackware kratunko Slackware 30 08-12-2005 01:31 PM
Slackware features? rusty_slacker Slackware 49 12-02-2004 05:45 AM
what are the features of the new slackware 9? ethanchic Slackware 2 09-27-2002 07:15 PM


All times are GMT -5. The time now is 01:38 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