Hi,

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.

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).

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!

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.

0 members found this post helpful.

And your point? Kernel maintainers fix kernel bugs, right? What does this have to do with Slackware?

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]

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.

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.

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.

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.

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.

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.

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.

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.

"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".

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?

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.

How about this?

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: 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?

28 members found this post helpful.