[ANN] sbog: "sbopkg -c" on steroids

drgibbon · 02-19-2018, 06:22 PM

Quote:

Originally Posted by 55020

Dude, git exists

Awesome, my concept is totally redundant then

Quote:

Originally Posted by a4z

but I agree that the redundancy we have is a bit a pain, and it would be nice to have everything in the Slackbuild, but therefore more flexibility, like arch scripts, but this will not happen too soon, or ever

It's definitely annoying to have it stored in two places! Would be nice to see this streamlined.

Quote:

Originally Posted by dederon

@drgibbon: from the user pov sbog works like sbopkg -c, and i have no intention to change that, the "sbopkg way" is reliable and has never let me down. that means, sbog will check for changes to the version or build number - nothing else (*if* i am right, after reading more of the sbopkg source the next days i know more. chances are very high that this is the case.). if you think this is insufficient for handling upgrades then please open a new topic for a discussion, this topic is not the right place. if you find a difference between the the upgrades lists that sbopkg -c and sbog will print then this is an issue that has to be resolved.

Ok, but SlackBuilds are sometimes patched without a change in the build number (then there's all the md5 stuff too), but I'll shift discussion of the Ultimate SBo Update Checker® to another thread

dederon · 02-24-2018, 03:22 AM

i released version 0.2. you can find download links and checksums in the starter post.

there is one notable change: the test command will execute the .info files and compare the VERSION in said file with the version scraped from the .SlackBuild file. In case of a mismatch an error message is printed.

running "sbog test" on the slackbuild master branch gives us this output. beside the parse errors there are a lot of mismatch errors. as i will point out below all of them are false positives.

i've learned by examining the output that some slackbuilds will append a string to the version number (which cause the fals positives), many of them in a way like

Code:

 
klibc: slackbuild version (2.0.4_4.14.11_smp) differs from info version (2.0.4)

the appended string is the release version of the running kernel ("uname -r"). thats a neat trick to flag a kernel-dependend package outdated as soon as the kernel is switched. the downside is that the installed version differs from the .info VERSION.

some other packages append language related strings:

Code:

 
openoffice-langpack: slackbuild version (4.1.5_en_GB) differs from info version (4.1.5)

ignoring the "append string" false positives, we get:

Code:

 
worldofpadman: slackbuild version (1.5) differs from info version (1.6)

looking at the slackbuild i realized this is a false positive too, as this package does some nasty trickery with the version. so we have numbers and therefore, answers:

1. are the .info VERSION informations up to date?
yes, there was no version mismatch beside the "append string" cases! congratulations to the slackbuild.org maintainers, you do an awesome job. i'm impressed. do you have some kind of automatism to set the version numbers? some scripts maybe?

2. are the .info files a reliable source to find the installed version?
depends, in 30 of 6983 cases the versions differ (because of string appends), thats about 0.3 %. if you can live with that, then the answer is: yes. a way to solve this issue would be to verify the prefix of the installed version with the VERSION found in the .info file, as the version number are only altered by appending characters,

next on the sbog dev agenda:
implement network related functionality:
- ping: check if the DOWNLOAD links in the .info files are working (maintainer command)
- get: download slackbuild sources and verify checksums (user command)