I wish the change logs included some details on the Added programs.

ap/ddrescue-1.14-x86_64-1.txz: Added.
Is this a new requirement/replacement of something? Or just a worthwhile addition

x/xdg-user-dirs-0.13-x86_64-1.txz: Added.
Why? Is it required by something else? Were we missing something without this package? Or just a nice addition to make the xdg package more complete?

I like how the security updates give a link to the CVE report, or at least a notation to the problem. Same with applications that are rebuilt ( extra/bash-completion/bash-completion-1.3-noarch-2.txz for example )

1 members found this post helpful.

Well, I suppose I can answer those inquiries. ddrescue is just a nice addition that several of us have needed in the past. On the other end of the spectrum, xdg-user-dirs is another item freedesktop.org is forcing us to include, in this case because the next xfce will require it. I can't honestly say that I have a good opinion of any of their xdg-* compontents which generally strike me as poorly thought out kludges, and this one isn't changing that for me. There's already a report that running the update script may corrupt directory names when used with a non-US, non UTF-8 locale, and it's also creating some surprises such as Terminal opening in the Documents directory. Not much we can do though... we don't have much sway over those inventing the standards. Bug reports should be sent upstream. Unfortunately several of these projects have a tendency to make fixes in the repo and seldom issue fixed tarballs.

Sorry, had to rant.

10 members found this post helpful.

No, salix provides dependency support for all standard slackware packages too.

edit: And it means exactly the same dependencies for all patched packages. Except hplip and wpa_supplicant, which in fact need less dependencies as qt support was removed.

2 members found this post helpful.

Excellent, thanks for the info

I have run into major issues with Slackware in the last year while trying to install software, and they all lead back to one cause...they lack of Python development headers packaged for Slackware.

In trying to get help installing several programs (most notably Anki), I got several of those "unhelpful posts" asking, "Why don't you try another distro?" only now I can understand why.

There are so many reasons I prefer Slackware I don't want to get into it, but mainly, I find many of the so-called "easy-to-learn" distros to have the same issues as Windows. (No offense, just my opinion after years of experience with Slackware, which I find easier because everything is so straightforawrd and because it avoids "dependency hell" as someone already mentioned.)

Python, however, imposes its own kind of "dependency hell." In a nutshell, many programs that use Python on the desktop require development headers. My experience was that no one could point me to finding the source code, only distribution-specific packages. Once I finally located source code, no one had any suggestions as the correct order to install/rebuild various libraries, and no such list could be Googled anywhere. Every attempt required starting over with my Slackware installation, and I just gave up.

Hence, I have to suffer with an XP laptop so slow it takes 6 minutes to boot to desktop and I cannot even run SP3!

So it seems the "unhelpful posts" were really on-the-ball in this regard...there's really no-way to get Python dependencies correct without switching distros, from a user perspective. Python dependencies are out of the league of a computer-literate user...it's a job for an expert.

I'm finding more and more software jumping on the Python/sqlite bandwagon. I love Slackware for every other advantage it has (it's easy yet powerful, flexible yet stable, command-line oriented yet simple to configure). I hope that Patrick will address the need for Python header files and other dependencies in Slackware...and not stick them in "extra" either...the superior install routine gives us all the choice we need for those that don't want to install it.

+1 Xavier!

Those who don't like a package shouldn't be trying to force that preference on others. Slackware is the most powerful distro there is because it gives everyone freedom of choice, and makes this freedom easy -- merely check/uncheck what you do/don't want during Setup!

Slackware shouldn't try to be like other Linux, shouldn't favor "minimal" versus "full-featured" preferences, it should embrace all users...no offense intended.

If my sleepiness made my previous post confusing, I apologize. To clarify the above statement:

I do not mean that I want automatic dependency-handling in Slackware. (I won't expand the reasons, which have been fully discussed by others in this thread.)

What I meant is I hope Patrick will include python-devel and many other python/qt/sqlite-related packages and header files in Slackware in the future, as increasingly required by several popular, one-of-a-kind software packages. (I use Anki as an example because it's a deal-buster for me, but there are others out there, which I can't recall at the moment.)

Slackware doesn't do *-devel packages, They're generally included in the package of the thing they belong with. This is one of the things I've always liked about slackware.

Perhaps you might be better giving us a specific example of something you believe is missing

1 members found this post helpful.

To be honest, avoiding installing KDE is much more complicated than it seems.

In L set we have a lot of KDE-specific libraries, starting with the famous Qt. Maybe we should move all the KDE-specific libraries in the KDE set, or even in its own set, KDE_LIBS?

0 members found this post helpful.

Python headers? Aren't they all those .h files in /usr/include/python2.6?

Out of curiosity, why would a Python program require development headers just to run?

I would not agree to that. You know, Qt is not KDE specific at all, I run applications here that do not care about KDE at all but do have a Qt interface (VLC, qbittorrent for example). Other packages in "l/" series sucn as akonadi, nepomuk maye be required by KDE but who says that other apps would not like to use those as well?

Eric

1 members found this post helpful.

I also use Qt based apps such as VirtualBox's GUI but have no wish for KDE, so the current situation suits me just fine.

They're definitely not required to run, but if you wanted to build a Python program that has C extensions as a part of its source, then they would be required.