I've only recently started using the 3rd-party Slackware package managers, and what a great addition they are! Until now I maintained my own small group of machines manually, but quite a number of my friends and family are so fed up with Microsoft's aggressive behaviour I've ended up installing Slackware on their machines too.

Which brings me to sbotools and slackpkg+. I can see that they should, in theory, make life a bit easier maintaining anything more than a handful of computers, but in practice I found out yesterday that the same software in different repos can throw a spanner in the works.

To put these tools through their paces I tried installing blender, kdenlive, cinelerra, audacity and ardour, from slackbuilds.org, using sboinstall. I first installed ffmpeg, however, from the alienbob repo, using slackpkg+. I now find that slackpkg upgrade-all wants to downgrade several dependencies brought in by sbotools.

What is the solution here? Blacklisting? The prospect of maintaining a blacklist of all the multimedia dependencies is not appealing, and would negate the benefit of using the package managers in the first place. I could omit the alienbob repo from slackpkgplus.conf and find 99% of what I need at slackbuilds.org but that would be at the cost of more recent software like Eric's ffmpeg, wine and vlc.

Were these troublesome dependencies installed by you from both sources (i.e., multiple versions of the same libraries), or do you mean that you only installed them from SBo and now slackpkg is trying to replace the SBo versions with the ones from Eric's repo?

I installed all but ffmpeg from sbo. See attached file for slackpkg upgrade-all results. It also wants to downgrade qemu 2.6.0 from sbo to qemu 2.5.0 from alienbob.

Attached Thumbnails

 

Interesting. I didn't realize that would happen. I suppose one other option besides blacklisting would be to not use slackpkg for the alienbob repo (since you only need a few packages from it), and just install those ones manually. Granted, that's not an ideal solution, but it might be less trouble than blacklisting a bunch from SBo.

I think you're looking for the greylist option of slackpkg+

Unfortunately, I don't have much experience with it, so my recommendation would be to just blacklist all SBo packages from slackpkg, as that will completely solve your problem of any downgrades presented by other repos. The downside is you wouldn't get any newer versions if (for example) Eric's version is newer than the version on SBo.

That's what I was thinking. Slackware suddenly feels more fragile when you start doing that though.

Greylisting is interesting. I'll study it more closely tomorrow. At the moment I'm just assessing the alternatives on a throwaway machine.

Hello,

if your main source of softwares is SBo and that you grab only some packages from 3rd-party repositories with slackpkg+, then it's simply better to add SBo packages on slackpkg's blacklist (ie. add [0-9]+_SBo in /etc/slackpkg/blacklist).

Using greylist in this scenario will only complicate package management. Furthermore, greylist only works in dialog mode, and thus, execution of slackpkg in batch mode could lead to unexpected upgrade/downgrade. Example :

--
SeB

2 members found this post helpful.

I do something like you but I don't install sbos directly. I put them in a private repo and install from there. I have never had this problem.

1 members found this post helpful.

Doesn't slackpkg+ take into account the package name tag when deciding priorities?

Yes, but only for repos that it's actually tracking. You can't track SBo with it, since it's a repo of SlackBuilds instead of packages.

Slackonly? http://packages.slackonly.com/pub/packages/

Yes, that would be a good option if the OP wants to use it instead of using the SlackBuilds directly from SBo. Just set slackonly higher than alienbob in PKGS_PRIORITY in /etc/slackpkg/slackpkgplus.conf.

I could be wrong, but I believe sbotools only fetches source code + slackbuild, then compiles it with all defaults, then (optionally) installs the resulting package.
If that is so, then it is no different than using the slackonly repo.

If, however, sbotools actually allows a user to specify any optional dependencies or parameters, then said user can build a local repo with just the required packages and point slackpkg+ to the resulting repo.

My point is: it is best to avoid using several package managers that may or may not be aware of each other's installed packages.
And since slackpkg+ is able to use the official slackware repos as well as third-party repos, it is a clear winner for me. Kudos once again to zerouno for making such a marvelous "plugin" (and also to all that contributed code and ideas to it).

In an ideal world, slackpkg+ would be merged with slackpkg and included in slackware proper pre-configured with repos trusted by the BDFL himself (he already publicly stated he trusts alienbob's repos by using Slackware's GPG here and here and I'm sure he trusts others in the core team as well)

Hello!

That was easy! I need to spend time getting all of this together in my head instead of muddling through.

The lateral thinking of a professional. Merci mon ami.