slackpkg+ priorities
 

I am using sbopkg with ponce's SBo repo for slackbuilds on -current.

I am also using slackpkg+, with PKGS_PRIORITY=( csb restricted alienbob ).

I notice slackpkg sometimes wants to downgrade or "crossgrade" a package - libxkbcommon from 0.8.4 to libxkbcommon 0.8.3, for example.

Or lua 5.1.5 in the ponce repo to lua 5.1.5 in the alienbob repo.

How should we deal with these dilemmas? slackpkg+ obviously doesn't handle package priority for SBo packages handled by sbopkg.

If you don't want to accidentally downgrade, or crossgrade, a given package that may be in different repositories you can try adding the package name to the "greylist" config file for slackpkg+.

Packages listed in the greylist still show up in the list of available updates, but unchecked by default. This helps ensure you don't accidentally install the wrong version, and it still allows you to see that other versions are available for that package.

Or you can simply add all SBo packages to your /etc/slackpkg/blacklist

As far as I know, this should prevent slackpkg+ as well to not list any updates to those packages.

Thanks. Only trouble is, when you have a long list of libraries. I'll look again at blacklisting, as suggested by bassmadrigal. As far as I remember, there are situations in which you are advised not to blacklist when you use slackpkg+, so I think I need to RTFM once more.

My best guess is that for a long time we would always set slackpkg (regular, not slackpkg+) to blacklist SBo and alien, as those were the two most common places to get apps, and some of alien's could replace stock packages (including multilib).

On slackpkg+, if you used those repositories, you'd *have* to keep them off the blacklist. But considering SBo typically does not replace stock packages, the only time you'd run into it is if you preferred to use alien's packages, but your automated SBo tool overwrites them (like sbopkg build and installs qt5 as a dependency for another program, and it overwrote alien's qt5 version).

Note: "sbopkg -k ..." doesn't build already installed.

Yes, I use sbopkg -kBi PKG

Having multiple package managers will make it difficult to keep a tidy system (too many cooks in the kitchen).

One way to improve things would be to create your own local SBo repo (using sbopkg, slackrepo, etc...) and point slackpkg+ to it.
This way you'll have only one tool to manage your packages their priorities.

You can also skip this and slackpkg+ point to an already existing SBo repo, although you'll lose a bit of control (you might have some optional dependencies when building some package, slackonly will build with default/essential dependencies).

For a number of reasons, I've switched to using slackpkg+. I've been using sbotools to manage and install software from SBo, but as indicated this has caused a couple of issues.

Blacklisting (/etc/slackpkg/blacklist) works fine for preventing slackpkg+ from messing with SBo software. The problem seems to be the other way around. The tools used to manage SBo don't appear to have a simple blacklisting feature. The only one I've found that appears to do this is sboui which simply provides an ncurses interface to other SBo managing tools. It does, however, provide package_blacklist that does exactly what's needed:

While this works (and works well), it means there now have 3 moving parts to package maintenance: slackpkg[+], sbotools[/sbopkg], and sboui. Not ideal (although I really do like sboui).

slackrepo may work for this (I need to look at it closer), but the issue with creating a personal SBo repo is that you still need to install most of the packages during the building process because of dependencies -building a dependency without immediate installation can/will cause subsequent builds to fail. As a result, trying to use slackpkg+ to manage a personal repo ends up requiring a VM/chroot env to build and install prior to populating the repo anyway. For managing personal systems, this would appear to defeat the purpose.

The last updates to slackonly appear to be July of 2018. Not a deal killer, but not ideal either.

Bottom line: It seems to me the best options would be to add a blacklist capability to first line SBo tools (like sbotools/sbopkg) - unless I'm missing that capability somehow now. Sboui works for blacklisting non-SBo software now, but can be cumbersome.

sboui does have its own built-in package manager now, in case you want to replace sbopkg or sbotools. It doesn't make much difference in actual usage though, because the package manager working in the background is more or less transparent to the user.

As a side note, I'm not sure why sbopkg and sbotools have never implemented a blacklisting feature.

That's a good suggestion. So the idea is to build packages with, for example, sbopkg, without installing them, and then let slackpkg+ install them? That way slackpkg+ doesn't present these conflicts to the user?

That's good to know. Thanks.

I wonder the same. Just not part of the 'purpose' I suppose. slackpkg for stock Slack, and SBo for external software. Just not meant to deal with non-standard repositories. Keeping it simple, I suppose.

As mentioned earlier, how would this work for creating packages like vlc? Or anything with a 'REQUIRES' line? You'd have to build and install the dependencies before building and creating a package for your main target. No? Unless you use a VM or other environment to create your repository.

hmm, good point. I'm ten years at Slackware now and I still haven't become comfortable with the workflow needed for third-party packages.

slackrepo is designed to work in a clean environment (like a VM, container, or a standalone machine). It will create a chroot and will compile packages in there and then destroy it when it's done (keeping the build machine clean). As dependencies are required, it will install them in a chroot and run any profile scripts and add any users to the system that are required for them, and then again, destroy the chroot once the parent package is compiled. It will do this throughout the whole dependency chain.

The only downside with using slackpkg+ to install from a slackrepo generated repo is it doesn't know anything about dependencies, so you'd either have to manually go through and check or just install everything. If you use something like slapt-get, it is able to resolve dependencies, so you can just tell it to install kodi, and it will install all the dependencies for kodi.

NOTE: While you do need to specify any users or groups required for package compilation, they are not provided in the package itself, just temporarily created in the chroot during slackrepo's build process. You will still need to create any users or groups required by the programs manually when installing the packages.

With regard to slackrepo, and the other tools used to build and install slackbuilds, my opinion is that the tool itself should be part of Slackware. I tried to visit the slackrepo site a few days ago and it was down. It hardly inspires confidence in the long run. And it's nearly 4 years now since it had an update.

I don't mind dealing with third-party repos, but at least some of the tools used to deal with them (slackrepo, sbopkg, sbotools, slackpkg+) should be given a more secure footing, preferably by shipping them with Slackware itself.