I dont agree with this to some extend, certainly not from a packaging point of view, the one im interested the most.

Slackware has the big advantage of not having a dependency resolving package manager.But thats right about all the flexibility you get, plus it also comes with disadvantages

Pat , at least from what i can tell, builds all Slackware packages in a full Slackware installation. That leads to many issues if you dont want to have a complete installation of Slackware. For example i have yet to find another system where samba links against dmapi. Only Slackware. Thats partly cause with automatic dependency resolution you know exactly how you to build the package, and usually most other distributions build them inside clean chroots, so theres no surprises there. But Slackware doesnt have that.

Then there's also aaa_elflibs. Thats the most evil package in Slackware, and as thrice` in ## calls it a crude hack.
The system is (most of the times) unusable without this package. If you dont install it you'll most likely have to maintain a streamlined version of it yourself.
Otherwise, at one point or another you'll want to build a package not in Slackware, and thats when that package is gonna link against something you dont want it to link against.
I can understand why this package exists, it offers (mostly) *Pat* and not the users (like i think its documented somewhere) a safety net, for example in case of soname bumps that affect almost the entrire distribution, to just throw the .so in elflibs and avoid rebuilding the whole lot, like its the case now eg. with libpng and libgjpeg.
I just dont understand why this package has to have *all those other* libs in there.

When people complain for the fact that Slackware assumes a full installation, Slackware users reply that hard drive space isn't a concern anymore in recent times.
So let me ask, if that is so why does this package exist today in its current form?
Why the aaa_* and *-solibs packages?

I know, those are just details, details that bother me though. IMO details matter and make a difference.
IMO Slackware doesnt offer you neither total control, neither allows you to set up a system *exactly* the way you want at least not without messing *far too much* with it.
IMO all of Gentoo, Arch, and even Debian to some extend (with its Recommended and Suggested packages) offer more control on the applications that will be installed on the system.
I dont claim that those systems are perfect, not even better than Slackware.
Just that Slackware could be a lot better.

On the other hand Slackware is perhaps the only distribution today where you can even attempt to use it without udev. This does indeed count as flexibility, one of invaluable form, one that can not be found anywhere else...

edit: PS. thats my own Slackware story..at least part of it

Hello!
I don't mean to be evil.Do you mean that you always must get some pkgs you don't need.
if >but everybody can compile their own system to source with or without needles things..And somebodys (like me) need full os,cause they haven't knowledge to do otherways.I install usually hole staff first and removing needles pkgs.That way I see how it works and looks.Without package manager it's more funny, you newer know what happend
All best...

Why do you start a new thread,
with a quote from another thread?

Kind regards

In order not to rerail the other thread which is meant to collect Slackware user stories, not start a discussion.
So Sahko did the right thing.

Eric

1 members found this post helpful.

You say there are problems most of the time if aaa_elflibs is not installed (but all other packages are), but can you provide even a single example of this?

5 members found this post helpful.

Thanks for the reply.
Probably more than one. The latest being liblzma.so.0

A large part of the flexibility provided by pkgtools by not selecting to install *libraries* part of the l/ group, which by definition is what packages link against, goes *poof* if you are forced to install aaa_elflibs (like i claim).
Being able to skip a/splitvt, ap/amp or n/nn is something i wouldnt consider that much of customisation of the installation.

Thanks. There have been a few rare examples in -current where something in aaa_elflibs was needed for a few days until everything was recompiled. But there's nothing in Slackware that requires anything in aaa_elflibs right now, and there never is for a stable release. And further, since there are no header files or *.so symlinks in the aaa_elflibs package, nothing will ever mistakenly link against it.

I think any problems you've had with aaa_elflibs are covered by the CURRENT_WARNING disclaimer.

1 members found this post helpful.

Those distros require a lot more effort to sort out dependency hell issues.
No thanks, I will pass. I choose Slackware and find it to be far superior to the OSs you mentioned with regard to control and stability. There are a known set of programs that are required for Slackware to work out of the box. I can live with that. Users who know what they're doing can safely select a package set that differs from a full install. I like manually sorting out dependency issues as needed. Dependency package managers are a fine thing when they work. Each to his own. I've used Debian and Arch.

1 members found this post helpful.

Only to notice that CMAKE, but also some AUTOMAKE builds, have the bad habit to search right to specifically .so libs. To make the things funny, some packages have something like "compat" headers; so, the build can do an auto-configuration on the case of 'bad' headers.

The lack of library headers don't guarantee that this library will not be used, especially when works the evil called CMAKE.

Still, you should have been in ## when the xz upgrade happened, and loads of people updated their KDE desktops with slackpkg which has aaa_elflibs blacklisted by default in its config. It wasnt nice, there were hundreds. That happened cause elflibs is weird, and uneeded.

As for the current warning, as you have said yourself when someone told you that Slackware is mostly used on servers that theres no numbers on that, implying (imo) the opposite, you cant really expect from desktop users to stay with stable, especially with the state KDE was until 4.6.
edit: and to some extend still is, if you take PIM and Office into account.
FTR personally i was never affected by any of these issues. The development branch of Slackware is the most stable tree of a distribution ive ever used, and continue using.

Well you are using -current knowing that there are risks associated with the development branch. I'm not sure I follow your point.

2 members found this post helpful.

I have never seen this happen before. My boxes have aaa_elflibs installed, so by now I would think this would have happened if it's a problem. Can you give an example of something using cmake or autoconf that picks up an old library from aaa_elflibs? If I can reproduce this issue here then I can look into ways to mitigate the problem.

Due to the fact i dont like it when i ask people questions and they for whatever reason neglect to answer them, here you go:
I had initially posted this in that other thread, but requested for it to be moved, in order not to hijack it. I didnt make up the thread title on this either.

FTR heres another post of mine regarding elflibs: http://www.linuxquestions.org/questi...1/#post3643906

edit: PS. I am not familiar with the "squeaky wheels and grease" saying rworkman is talking about.