"because the road to
is paved with good applications"... 
Dependency hell
My use of the Arch repo came from a simple decision regarding "unetbootin" an application that I use for distros.
The Arch version of unetbootin is stable (on my systems). The Slackware version from USM is not (I have eight different systems).
Because "unetbootin" worked I decided to break out the cookie cutter (aka "one ring to rule them all..."),
because I'm a veteran of dependency hell. I did not go thru hell with Slax but I ran into it with Slitaz 10 yrs ago.
Here's what I've found with Arch. It's repo is a poster child for dependency hell...
However... it's a walk in the park compared to Fedora/RedHat which to me is the mother of all dependency hells.
At the end of the day... bundling with the Arch repo using pkgs.org is a painstaking tedious chore...
And the result (success?) of each chore has to be determined on a case by case basis.
More simply put... if it works it's a winner. If not... find a workaround. Otherwise... move on to something else...
My approach is to use the Arch repo to determine which Slackware dependencies to use.
When I make a bundle I test the modules for corruption first. I also look for common denominators like...
"glibc" (or better still "musl")... "gcc" (or better still "tcc" and/or "llvm")... "systemd" (or better still "uselessd").
I believe the downside of the Slackware repo is... some packages may lack dependenices that would stablize and/or improve them.
I believe the upside of the Slackware repo is... it's packages terminate with few levels of hell.
Best Regards...
