It has been a while since the last stable iteration of Slackware stable (14.1) was released and we are on the cusp on 14.2. Who knows when the next stable iteration of Slackware will surface? Over the years I have used Slackware stable on older machines for multimedia production (graphics/audio work) in addition to regular computing tasks. However, I updated my desk and laptops and found that Slackware 14.1 did not work as well on those machines and configuring them for compatibility was way more trouble than it was worth. However, as the new 14.2 release candidate iso's were made available by AlienBOB, I decided to give them a whirl. I was pleased that the rc candidates worked nicely on my newer machines.Unfortunately, when I tried to get multimedia programs installed like Inkscape, I got into trouble. What libraries to install? I got inkscape to work, eventually. But 'slackpkg update' knocked that all down with messages about library conflicts. A visit to the Slackware IRC about the issue brought derision when I asked about a good way to track dependencies and to ensure minimum conflicts. I think a lot misinterpreted my question as a request for a package management system like Debian's 'apt-get', which is not the case. They further asserted that Slackware current is strictly for users of the default packages that comes on a DVD install and anything outside of that would require another distro. What I was asking for was whether anyone does install multimedia packages like say, Blender, Inkscape, Scribus and such on current and how do they manage software libraries? Stable is an ideal case scenario, but sometimes the release gaps make this not feasible. Or is software installation on Slack current really something only Jedi Knights like AlienBOB, Volkerding, and Workman can make happen?

Now current by nature is unstable, yes, I got it. However, we are also in a bit of a grey area as we approach release candidate territory. I suppose that is my question, is there a realm between light and shadow--a 'Twilight Zone' between current and stable where one can get programs running when the stable release gaps grow? Or would such a thing exist only in The Twilight Zone?

Using -current can be a great thing because you get the newer software and latest hardware support, but, as you have noticed, it can cause problems with 3rd-party packages. There are many who maintain a full installation, including many 3rd-party packages, while running -current, but it can certainly be a lot more work than a stable release.

Unfortunately, the simplest way to deal with your problems is to just recompile all 3rd-party programs whenever you notice any problems. If you have a lot, then it can lead to some lengthy compile times. Short of starting up each 3rd-party program and seeing if it errors out, I don't know of any other easy method to see if you need to recompile or not. With SBo, I know they don't track dependencies on software that is included with a stock Slackware install, so if -current sees an upgrade of libpng, you don't have any reference on SBo to see which programs you have that link against that older version (and sometimes, even if a program links to a library, an upgrade to the library doesn't require you to recompile the program).

For me, because I don't have the time (and don't want to expend the effort) to keep all my programs up-to-date with -current, I have my desktop stay on 14.1. Unfortunately, when I built my new HTPC, its hardware wasn't fully supported by 14.1, so I had to install -current. I kept up with -current for a few weeks until I felt my machine was stable enough, then I stopped (probably not the most secure idea, since I won't have any security updates that are put in -current after I stopped updating -- but I weighed that with the time it took for me to maintain the upgrades, and it just wasn't worth my time). During this time, -current went through a few big library updates, so I had to recompile my 3rd-party programs a few times (I just created a queue file with all of them in the right order and then had sbopkg work on it overnight). Once everything felt stable enough to me, I called it "good enough for now". Once 14.2 is released, I will update both systems to 14.2 and recompile all my required programs (actually, I'll probably compile them on a VM, so I can immediately install my programs once I get 14.2 updated rather than have a lot of downtime while everything compiles).

Long story short, I believe most will only recompile their 3rd-party packages when they run into problems while starting/using them. It can lead to some frustration if you need to use a program right away but then need to wait until it recompiles. But then they get to find those bugs and report them up so they can get resolved before the next stable release, so it can certainly be worthwhile, and you can learn a lot about your system.

2 members found this post helpful.

Blender comes in a tarball that you just unarchive into your home directory and then run. It includes all its dependencies.

In these repositories:
http://slackware.uk/salix/x86_64/slackware-14.2/
http://slackware.uk/salix/i486/slackware-14.2/
you will find information about dependencies in PACKAGES.TXT.

This information is mostly intended for Slackware derivatives that need it because they don't provide all Slackware packages, and the slapt-get utility can use it to propose to install the dependencies needed by a given package.

So you *could* install slapt-get and set it to use one of these repositories instead of an "official" mirror of Slackware-current. But...

• This is of course not "the Slackware way", so if you encounter issues maybe you won't get as much help in this forum as if you would use the genuine Slackware tools.
• In addition you would need to compute the dependencies of the package you want to install (Inkscape for instance), and in that aim you will need to build the package first (unless someone already did it). Kind of a chicken and egg problem.

This being said, in Alien BOB's http://slackware.uk/people/alien/sla...s/PACKAGES.TXT you will see some deps indicated (field PACKAGE REQUIRED) so you could use that for the packages he provides. Of course he assumes a full Slackware installation (I think) and I do not know if he still provides this information for the newest packages. If that is the case I think that you can safely use slapt-get with this repository, after having properly set up /etc/slapt-get/slapt-getrc.<arch>.

EDIT I realize that the previous paragraph is off topic. Anyway a correction is needed: due to the layout of .../alien/slackbuilds repository, to use it as source for slapt-get is not possible directly. You would need to make a local repo including only the packages that match your version and architecture, for instance with a relevant rsync command using --exclude and or --include options as filters.

That's all I know.

2 members found this post helpful.

On -current you'd just rebuild the software that broke due to library updates.

If you run stable, you won't have updates causing library issues. Ever.

Where did you get these additional programs?

If you got them from Alien Bob, look for a .dep file in the same place as the package. If it exists, it tells you exactly which of Alien Bob's other packages to install.

If you built them yourself via SlackBuilds.org, you just need to read the .info files and read the README files. But in some situations this becomes onerous, and there are tools to ease this burden: sbopkg with sqg, sbotools, and more.

But it is always assumed that you have a *full* installation of Slackware. Don't expect anything to help you with Slackware's internal dependencies.

I have never seen a "message about library conflicts" from slackpkg. Maybe it was some other tool you were using. You would need to be more specific, I'm afraid.

Edit: Do you mean, *after* you'd done 'slackpkg update', you got messages saying "cannot open shared object file: No such file or directory" when you started (e.g.) Inkscape? If so, well, that's life with -current. What bassmadrigal wrote above is particularly good advice about this.

Unfortunately, that happens a lot on ##slackware. IRC isn't really suited to resolving misunderstandings. Welcome to LQ!

The length of time since 14.1 is unprecedented in Slackware history -- but not much more than (for example) the gap between Ubuntu 14.04 and 16.04. Possibly it relates to the security flaps of 2014/15, during which 14.1 received a great deal of maintenance. I wonder what exactly you consider "not feasible" -- new hardware?

*No*. Until the very day 14.2 stable is released, any package upgrade in -current can and *will* break packages that you built locally and require you to rebuild them. That's the deal.

Metaphors don't help anyone

During the last two development cycles (14.0 -> 14.1 -> 14.2), LQ member and SBo admin Ponce has made available an unofficial git repository where SlackBuilds adapted for -current can be contributed. Then, towards the end of the last two development cycles, SlackBuilds.org has frozen the old branch and (building on the work in Ponce's unofficial repository) started to work towards the official new branch, which is publicly available alongside the old branch. This is the exact situation today. Of >5600 SlackBuilds, only nine still need more work. *However*, until 14.2 is properly released, updates of Slackware will continue to require unpredictable rebuilds of your SBo packages. Getting to know well the tool of your choice (sbopkg+sqg or sbotools -- there are others too) would make this less of a bother. And then when 14.2 is released, you'll have no more bother, if you use the tools properly.

3 members found this post helpful.

Thanks to those who responded, but I like Bassmadrigal's best because it feels most relevant to what I am looking for. What I did was use sbopkg with the current repository however when getting packages together for Inkscape, which requires a lot of libraries, I noticed most of what I needed was not there. I used slackbuilds.org as a reference and then went to the library sites directly and tried different versions until the install went through. I modified the slackbuilds to reflect the versions I was trying to install. I aimed for new-ish, but not the newest and if an install failed, I stepped back a version until it did not. Only one case did I have to use an AlienBOB library which installs smooth, but doe snot give much feedback like a regular slackbuild. So I used a combination sbopkg, slackbuilds, and AlienBOB packages to get at what I wanted. After I worked on a vector graphics project I later did a slackbuilds -update and got a message about library conflicts, I cannot recall what it said exactly except that it specifically pointed out more than half the libraries I installed for inkscape and said that there was a problem with them and I had the option to ignore, overwrite and some others. I was also warned that if I did not resolve this problem immediately I was going to be in trouble so I let it overwrite and most of my libraries were gone. (Because I am newb-ish).

Didler (I also like your post), the Salix 14.2 link you provded led to a dead end, but I have no issue with using another way to install packages if it gives me the programs I need. I will look into Salix more. I will also look into the AlienBOB installs.txt. I know AlienBOB has an Inkscape package somewhere and I will look into his documentation further. Maybe he has a comprehensive library list in there complete with versions I need.

So I was asked by someone, why bother to work with Slackware at all if I can use another distro to avoid these headaches. I use a lot of distros accross machines, in addition to the likes of Windows for multimedia stuff. Take Ubuntu 14.04, stable, which seems to be the fallback distro for me. When I run Inkscape, on my machines running Ubuntu 14.04, I have an issue with toggling the font menu, itglitches out on me. Also, Inkscape takes about a minute to load on Ubuntu--and I have decent hardware. With Slackware, even when my libraries are a Frankenstein of versions, it launched in ten seconds and I had zero issues with toggling fonts. Yes, installing is a pain, but stable or current, if I get it to install, it works like a beaut. Ubuntu is okay, but there are these weird glitches that make for a frustrating experience, otherwise I would not leave them.

I am an ignoramus in Slackware and when I get other hardware, will probably go through these issues again. However, I like reading about the libraries and discovering weird packages named "beautiful soup" and reading about what it does. But this is also a time killer when I need to get work done. But I yearn to play with the big boys instead of crapping in my huggies.

Yes, there was a typo in the first link, sorry. It is fixed now.

In general I would say that if you want to run a lot of specialised software, requiring new versions of many dependencies not available in the main Slackware tree, it can indeed become a bit tricky to keep track of it all, I would then consider something like Void Linux (if you see all you need in its repos of course).

Everybody has their own way of doing things as you see, but I wanted to install inkscape again, I would personally:
- go with slackware current for the moment, many of inkscape's dependencies are now in fact included
- install slackpkgplus, add alienbob's repository to be able to easily slackpkg install BeautifulSoup.
- slackpkg install his python-lxml package as well, hoping that it'll do to satify inkscape's lxml dependency.
- download the slackbuilds from ponce's repository (already mentioned by 55020) to make slackpackages for numpy and inkscape itself. Only a couple of packages to manually keep track of, this way. (If the python-lxml of the previous step was not sufficient, I trust the build will complain about that and fail, then I'll have to build lxml too.)

use software from slackbuilds.org
like https://slackbuilds.org/repository/1...hics/inkscape/
it will list dependencies, you can make queues, rebuild them if required,

if you are on current and you find a problem, there is a thread for such things
http://www.linuxquestions.org/questi...ls-4175561999/


additional you can use sbbdep to get information about binary dependencies

you can check before you update what will be effected by using the whoneed option on a package
this will give you a list of what you might want to rebuild

you can check after you updated if all binary dependencies are still valid

check the documentation:
http://a4z.bitbucket.org/docs/sbbdep/