@gnashley, I've read your post several times now and I like it more each time

More *information* about dependencies is good, for all the reasons you give, and also it helps developers and packagers to minimise dependencies. But if the developers and packagers do their job properly, end users shouldn't need to know, unless they pretend that they are developers by running -current

Using that information *automatically* is bad, because it means *people* no longer care about minimising dependencies, and it leads to crazy situations like rpm depending on seamonkey, or the whole gnome mess.

If I could please waste a few moments of everybody's time on a hopeless rant, the whole dependency problem is caused by Unix not having proper dynamic linking. Unix merely has delayed static linking. On Multics, you didn't need to snap links at load time. Linking a segment happened when it was *called*, and you could even patch it in *after* a linkage error and resume your application as if nothing had happened. If you never *invoked* a missing segment, there was no problem. Of course Multics did this with segmentation instead of stupid flat memory

I agree 100%. Guidance is good, forced compliance is not.

And that's perfectly fine, I don't need to know which package is required to build and which one is required for certain feature, I just want to compile the program and get it working as expected! :-)
I like to tinker with the system, many times I had changed default compile options in order to avoid compiling certain library if it was required only for a feature I knew I wouldn't need. But sometimes I just want to get the program working and move on.

Of course, I am referring to SlackBuilds on SlackBuilds.org, which are not part of Slackware, and therefore this comment is probably offtopic :-D

Regards

What i would like to see in Slackware?
1)Better choices. For example Samba 3.5 was buggy and a bad choice for Slackware 13.1. Version 13.0 had the worst IMO kernel for ext4. (2.6.29)
2)A way to to install a minimum system (core) without X and a way to install a system with just X and XFCE. It would be nice for servers and old computers. Not all of us need KDE 4X libraries.
3)Dependency checking. Some people claim that the reason they prefer Slackware is because it doesn't have a tool like apt-get. But lets be honest here. If someone doesn't like dependency checking then he can simply disable it. Such an option is available to slapt-get. So it's just a bad excuse. Personally i believe that Slackware doesn't provide a tool to resolve dependencies either because Pat doesn't have the time to do it or simply he can't. (But i highly doubt for the second.)

Not a bad first post, Xspartan, and welcome to LQ.

I just want to point out that this last bit is a bit inflammatory:


We've just gone though several pages in this thread on that very topic. More to the point, Pat has explicitly stated why he doesn't have dependency checking in Slackware, and it's not the two reasons you posted.

Personally, I think it's fair to debate the merits and consequences of dependency checking in Slackware, but I don't think it's fair to speculate on the maintainers' motives on the issue.

Regards,

1 members found this post helpful.

Ty for the welcome. Believe me, i do not wish to start-up a flamewar or something. I am a Slackware user too, after all. And i can mention 1000 reasons why i prefer Slackware over Ubuntu. But the topic is "what changes would like to see in future Slackware".

Xspartan,

I could tell that you're a slacker.

Welcome again.

Welcome to LQ!
The above statement does put our Slackware maintainer in a negative light. Perhaps that was not your intent. Slackware has no dependency checking by design. Remember, you are in the official Slackware forum. We all very-much appreciate and value what Mr. Volkerding does for our community.

FWIW, I still don't get the whole concept of dependency-checking as it relates to Slackware.

It's been said before (and said above several times), if you do a full installation of Slackware, then all the dependencies are already in place and you're good to go. If you install something that is not a part of the distribution, then you're on your own.

So the people who want dependency-checking seem to want it for one of two reasons:

1. They only want to install parts of Slackware and want to make sure that everything works, or
2. They want to install 3rd-party packages and have the dependencies checked for them.

FWIW, I don't necessarily think either reason is automatically a bad idea. I just thing that they're rather contradictory. If you don't want to install the distribution as packaged, then this leads to a situation that many distributions have where one installs a "core" and then picks what one wants after that's installed.

... which is fine, but that requires that the maintainers develop and maintain a lot more packages to accommodate the huge variety in software that people want to add to the core.

... which is fine, but that means that everything the developers maintain is still part of the distribution and installing something outside the distribution means you're still on your own.

Sure, third-party distributors can put together packages in your distribution's package format (RPM, .deb, etc.), and perhaps that's an advantage.

Serious question: am I missing anything here?

Regards,

sounds for me like you would like to use http://www.salixos.org
based on and compatible with Slackware and the points you mention are realized

Salix (Fluxbox edition) is already installed on my old Laptop

I love the "no dependency checking" of Slackware. I allows me to install whatever I want and whichever version I want.

Real life example:

I want to install xxy:
yum install xxy.
Version available: xxy-0.2 (released in 2004)
Last stable version: xxy-3.2 (released in 2010)
Ok, go to download xxy-3.2 and install it "manually".
Error, it requires libccx >= 4.5.
Last version available in yum repos: libccx 4.1.
Download libccx 4.6 and install it.
Error, it requires libzz >= 2.1.
Last version available in yum repos: libzz 1.8.



In the end, package management is more a problem than a solution!

Well, not quite
As mentioned in this thread, there is the "Slack with deps" project by STEFANO STABELLINI, does not touch the packages themselves.
He just modified the PACKAGES.TXT from the repository.

I do agree that Slackware should provide dependency info, just like slackbuilds.org does.
Providing info is not the same as auto-installing dependencies and I for one would be grateful.

As for what I would like to see in future slackware: a better organized repository (a "xfce" directory comes to mind) wouldn't hurt

1 members found this post helpful.

Dependency checking could be optional and not a default feature. Slapt-get or a similar tool could be in Slackware's cd extra directory. Just like Grub.

It would be really weird. XFCE itself is 12MB, with an extra mega from its other packages (thunar-volman, xfce4-notifyd, etc). What I'd like to see is thunar packaged separately. But I don't really know what thunar depends on so that might lead to an explosion of tiny packages. If that is the case, nevermind what I said.

I would appreciate the same gesture to provide dependency info of a package. It helps the administrator to learn what packages must be installed first or later in an installation chain, which is what a slackware admin does on a regular basis.

Something along the lines of: