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.

I just checked and the slackrepo site came up without issue.

https://idlemoor.github.io/slackrepo/

I don't think the download link works anymore, but that version was quite old and I think he prefers people to use git to build an updated version.

But I'm still using his original version (with three minor changes, one allowing me to remove required dependencies, one to allow me to compile programs with python3 if they don't support it in the SlackBuild, and the final allowing me to download jdk through the program) and it works without issue. Sometimes programs don't need updates if they're working without issue.

I don't think slackrepo is a good program for beginners with Slackware and still may not be worth it if a user is only maintaining a single computer, but if they want to host a repo that multiple computers can access or have excellent control over the build process (and to keep your system up-to-date, as it will automatically rebuild programs when their dependencies were rebuilt), slackrepo is amazing with it. It is what was used by Panagiotis to make SlackOnly.

The potential problem with introducing these is that is might make some blame Pat if 3rd-party packages break Slackware. He may only want to provide tools to interact with official packages/mirrors and let the community provide tools that interact with community repos.

Agree with this. I use only slackpkg and slackpkg+ to manage packages. I have my own repository as well. I use Alien Bob's repos_files.sh script to generate the needed files for the repository to work with slackpkg+ I use this with slackware64-current.

These are the applicable lines from my slackpkgplus.conf
The nonslack is my repository, multilib and ktown are mirrored locally.

The priority explained. A few packages (ffmpeg, id3lib, jansson, ninja) in the alienbob repository match slackware64 packages. If I only have 'alienbob' at the end of my priority list, those matching packages will be selected to upgrade the slackware64 packages. The only matching package name I want upgraded over a slackware64 package is ffmpeg. The 'alienbob:ffmpeg' does this by setting the priority for that package to alienbob. When I run 'slackpkg upgrade-all' the only alienbob packages that are upgraded are ffmpeg and the other packages I have installed from alienbob, but not the ones matching slackwaer64 package names.

It might not be the intended way, but it works.

When using search to test changes to slackpkgplus.conf though, the results are not always as expected.

With ffmpeg I DID get the expected result. It shows the installed version with the other matches as uninstalled(masked).

A search for one of those matching packages shows 'upgrade' from alienbob. I think it should show the alienbob package as 'uninstalled(masked)' and the slackware64 package as 'installed'.

Regardless running 'slackpkg upgrade-all' produces the desired results.