why does sbocheck/slackpkg want to downgrade certain packages?

slackmensch · 05-10-2021, 06:23 AM

I have slightly modified a few slackbuilds, built and installed the packages. Now it looks like sbocheck wants to downgrade them. I didn't make any changes in /usr/sbo/repo but copied the modified slackbuilds to my home folder. Is there some quirk/convention of naming that is causing problems?

Code:

> sbocheck

Updating SlackBuilds tree...
Updating files: 100% (35177/35177), done.
HEAD is now at cc056687aa Fixed typo
Checking for updated SlackBuilds...

fakeroot 1.25.3  <  needs updating (1.23 from SBo)
kaffeine 2.0.18  <  needs updating (1.3.1 from SBo)

Also, slackpkg+ wants to downgrade my qemu which was built and installed by sboinstall:

marav · 05-10-2021, 07:14 AM

You need to blacklist your SBo packages

In /etc/slackpkg/blacklist

Code:

[0-9]+_SBo

Alien Bob · 05-10-2021, 07:16 AM

Perhaps for a better understanding: Slackware's package tools do not know the concept of higher/lower version numbers. Just different versions.

marav · 05-10-2021, 07:32 AM

In other words, slackpkg will always prefer the version of a pkg who came from the repo you defined in slackpkgplus.conf, whatever the version

Code:

REPOPLUS=( slackpkgplus alienbob restricted )

As long as it isn't blacklisted

slackmensch · 05-10-2021, 10:00 AM

Quote:

Perhaps for a better understanding: Slackware's package tools do not know the concept of higher/lower version numbers. Just different versions.

I was wondering about what constitutes differentness: looks like all the stuff up to the first dash has to be unique or else pkg tools thinks it's the same package?

For example, I can't install kmod-zfs-5.10.35-2.0.4.tgz because there's a package called kmod-28-x86_64-3 installed. So I just rename it to zfsmodules-blah.blah.tgz. (The kmod-zfs-XXXX.tgz name is chosen automatically by something in the zfs-2.0.4 configure scripts.) These modules need to be rebuilt whenever the kernel changes, so I keep being reminded to ask about the naming of packages.

bassmadrigal · 05-10-2021, 10:47 AM

Quote:

Originally Posted by slackmensch

I was wondering about what constitutes differentness: looks like all the stuff up to the first dash has to be unique or else pkg tools thinks it's the same package?

For example, I can't install kmod-zfs-5.10.35-2.0.4.tgz because there's a package called kmod-28-x86_64-3 installed. So I just rename it to zfsmodules-blah.blah.tgz. (The kmod-zfs-XXXX.tgz name is chosen automatically by something in the zfs-2.0.4 configure scripts.) These modules need to be rebuilt whenever the kernel changes, so I keep being reminded to ask about the naming of packages.

This is because that package name is broken. Package names in Slackware require the program name, the version, the arch, and the build/tag. These are all separated by dashes and the program name is the only part of the package name that can have dashes with it. The scripts determine each aspect of the package name by reverse, so it will first determine the build/tag, then the arch, etc.

In the case of your two packages, here's how pkgtools see them kmod-zfs-5.10.35-2.0.4 and kmod-28-x86_64-3

So, your kmod-zfs package has a dash in the version, which pkgtools doesn't detect and it is also missing the arch and build/tag. So, pkgtools thinks that kmod is the program name, zfs is the version, 5.10.35 is the arch, and 2.0.4 is the build/tag. To fix the version, you'll need to swap the dash for an underscore (5.10.35_2.0.4) and then adding the arch and build/tag will fix the rest of the package name.

Once the package name is fixed, you'll be able to install it properly with no conflit from the stock kmod package.

IndiX · 05-10-2021, 02:37 PM

Quote:

Originally Posted by marav

In other words, slackpkg will always prefer the version of a pkg who came from the repo you defined in slackpkgplus.conf, whatever the version

Code:

REPOPLUS=( slackpkgplus alienbob restricted )

As long as it isn't blacklisted

Thanks!

marav · 05-10-2021, 02:57 PM

Quote:

Originally Posted by IndiX

Thanks!

the order of REPOPLUS is important too
and determining for the pkg that will be installed

Code:

REPOPLUS=( slackpkgplus alienbob slackers restricted )

will install pkg from alienbob before slackers

Code:

REPOPLUS=( slackpkgplus slackers alienbob restricted )

will install pkg from slackers before those of alienbob

And, It doesn't matter whether the version of the 2nd repo is higher or not

preater · 05-11-2021, 05:26 AM

I have the same problem to the OP with sbotools, and wondered if anyone has an equivalent solution to those mentioned for slackpkg and slackpkg+?

I'm using ponce's SlackBuilds tree for Slackware64 -current, and sometimes use these SlackBuilds as a basis for my own builds where the SlackBuild is out of date and I need (or want) a newer release from upstream. I don't change the sbo tree, like slackmensch I make a copy and edit the the SlackBuilds scripts elsewhere on my system.

It leads to situations like this:

Code:

$ sudo sbocheck
Password: 
Updating SlackBuilds tree...
remote: Enumerating objects: 648, done.
remote: Counting objects: 100% (648/648), done.
remote: Compressing objects: 100% (246/246), done.
remote: Total 648 (delta 402), reused 648 (delta 402), pack-reused 0
Receiving objects: 100% (648/648), 164.17 KiB | 1.67 MiB/s, done.
Resolving deltas: 100% (402/402), completed with 147 local objects.
From https://github.com/Ponce/slackbuilds
   3a3a588bbd..131e9a3123  master     -> origin/master
Updating files: 100% (35339/35339), done.
HEAD is now at cc056687aa Fixed typo
Checking for updated SlackBuilds...

acpica 20210331  <  needs updating (20170531 from SBo)
cronie 1.5.7     <  needs updating (1.5.4 from SBo)
nginx 1.18.0     <  needs updating (1.12.2 from SBo)

A copy of the above result is kept in /var/log/sbocheck.log

Thanks!

Slax-Dude · 05-11-2021, 06:59 AM

AFAIK, sbotools allows you to override packages from the SBO repo with packages from a local repo.

from documentation on sbotools.conf

Quote:

LOCAL_OVERRIDES=(FALSE|/path)
If set to a path, any directory name under that path that matches a slackbuild name will be used instead of anything found in the main repo. (By default SBo, but this can be changed using the REPO setting. See below.) This will even work if it isn't on SBo at all. It still requires all the usual files present in an SBo directory such as README, name.info, and name.SlackBuild

preater · 05-11-2021, 08:41 AM

Ah yes, thank you! LOCAL_OVERRIDES works perfectly if you keep your own SlackBuild files in the same format as SBo uses, and correctly formatted. I had read the fine manual but misunderstood what that option would do.

Andrew