SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Would the user with an already functional package really want to be notified of an update if the MD5 or download link changes?
Well, it depends.
Download changed, md5sum same => the source has moved but is still the same, no need to rebuild.
Download same, md5sum changed => upstream has changed the source (probably a bugfix) but kept the same version number. We all wish that projects would never do this, but they do... anyway, it needs a rebuild. Or maybe it's Github, where sometimes the md5sums change even though the source is exactly the same, so it doesn't need a rebuild.
Download changed, md5sum changed => maybe it has disappeared upstream and the only replacement we can find is a repack (remember when lots of projects moved from Google Code to Github?), so it doesn't need a rebuild. Or maybe the original download was wrong (sometimes the maintainer makes a mistake), so it does needs a rebuild.
If it might need a rebuild, then the safe thing to do is to rebuild. But the user won't rebuild if the user isn't notified.
Ok thanks, the situation is more complex than it looks on the surface then Perhaps the safest rebuilding would occur on version/md5/dep changes in info files, and also on changes to SlackBuild scripts.
I do think that information should be sourced from the info files, as it seems like a fragile situation to have to parse it from SlackBuilds, where weird/unforeseen scripts might break the updater's logic.
in theory, yes. but as i pointed out: i don't know if you can trust the info files. the truth lies in the slackbuild - the version saved in the slackbuild will be built, not the version in the info file.
to shed more light on this i will release sbog 0.2 soon (tm), which will extend the "sbog test" command. i didn't mention this command in my starter post, is it is meant to be used by repository maintainers.
in version 0.1 the test command parses every slackbuild in a directory for the package version and will print an error message if this fails. in version 0.2 sbog will additionally parse the info file and compare both package versions. then we know what we are dealing with and if the info files are in sync with the slackbuilds. still you need the slackbuild for the build number, which is not saved in the info file.
as i pointed out earlier, in the end it boils down to the fact that the package version is saved twice in the repository, which can lead to inconsistencies.
in theory, yes. but as i pointed out: i don't know if you can trust the info files. the truth lies in the slackbuild - the version saved in the slackbuild will be built, not the version in the info file.
<<snip>> ...
dederon --
I don't believe that is generally true.
The truth actually lies in the command line issued by the user because VERSION, BUILD, TAG and sometimes more SlackBuild Variables may be overridden from the command line.
I look at the SBo .info file as a config file for the SlackBuild.
Generally speaking, when there is a config file for a particular program which also allows command line overrides, the override hierarchy for a well-designed program probably ought to be:
Code:
1. Hard-Coded Variables in the program ( the SlackBuild )
2. Config File Variables override #1 ( the .info file )
3. Command Line Variables Override #2 and #1
At least that is the way I've written my program code since the mid-1980's
Since there are no .info files for Official Slackware Packages, the hierarchy is simply #1 and #3 ...
In addition, that same SBo .info file tells me everything I need to know to download and run an `md5sum -c` on the upstream source file(s).
Changing these assumptions would break the home brew / generated SBo build scripts that I've run for a number of years.
sourcing the info file before building the slackbuild would be great, it would solve all problems! i am not sure if sbopkg works this way, i try to make my way through the source code.
what is still a mystery to me: if the info file is parsed before the slackbuild is built (so the version comes from the info file), why does "sbopkg -c" try to parse the package version from the slackbuild and not from the info file? the info file is used as a fallback only.
see this comment from sbopkg source ("above" means: the process of parsing the number from the slackbuild):
Code:
# Step 5 - fixup braindead cases
# Sometimes the above doesn't work -- see cpan2tgz for 12.1
# In that case, let's trust the .info file...
[[ -z $NEWVER ]] && echo "Empty version!" >> $ERRORMSG
if [[ $(< $ERRORMSG) ]]; then
NEWINFO=$(sed 's/\.SlackBuild$/\.info/g' <<< "$NEWSB")
NEWVER=$(grep "^VERSION" $NEWINFO | cut -d\" -f2)
fi
maybe someone from the sbopkg team can enlighten me.
just to make it clear: i am talking about the VERSION only, not about the download link or the md5sum in the info files - these are fine.
If you can't trust the .info files, you can't trust the repository at all. Don't make your life more difficult than it needs to be. Use the .info files; that's why they are there.
I am an old-fart and the only package tools I use are installpkg, upgradepkg and removepkg after getting a-holt of a package.txz file and checking the integrity of the file.
So I don't know anything about sbopkg or the other package managers.
As far as I know, only SBo has the .info files ( the Official Slackware SlackBuilds and Alien Bob's SlackBuilds do not ).
That's OK ... not all Programs actually need an external config file ...
In that case, if you need the VERSION, the only way to get the default VERSION would be to parse the SlackBuild itself.
Then if there is an OPTIONAL .info file, override the default SlackBuild VERSION with the .info file VERSION.
Finally, if there is a command line VERSION override, use that instead ?
Anyhow ... that's how my home-brew generated scripts work.
-- kjh
This q&d bash script will get the default VERSION= string from a 'standard' SlackBuild Script ... it prints the last VERSION= line in the SlackBuild:
Code:
#!/bin/bash
[ $# -lt 1 ] && echo "usage: `basename $0` some.SlackBuild" >&2 && exit 1
File="$1"
#
# find line(s) with '^VERSION=' pattern ; discard trailing comments ; get the value ; print only the last instance.
#
grep -h '^VERSION=' "$File" |sed -e 's/ *#.*$//' -e 's/^.*:-//' -e 's/^VERSION="*//' -e 's/[\}"].*$//g' |tail -1
exit ${PIPESTATUS[0]}
It should handle any of the following formats, including an optional ( non-standard ) #-comment following the VERSION= assignments
Code:
VERSION=1.2.3 # no command line override allowed here
VERSION="${VERSION:-1.2.3}" # quoted assignments
VERSION=${VERSION:-1.2.3} # standard syntax
# If VERSION isn't set, snarf it from the SlackBuild:
local versioncmds prevdir
if [ -z "$VERSION" ]; then
# The next bit is necessarily dependent on the empirical characteristics
# of the SlackBuilds in Slackware, msb, csb, etc :-/
versioncmds="$(grep -E '^(PKGNAM|SRCNAM|VERSION)=' "$SR_SBREPO"/"$itemdir"/"$itemfile")"
# execute $versioncmds in the SlackBuild's directory so it can use the source tarball's name:
prevdir=$(pwd)
cd "$SR_SBREPO"/"$itemdir"/ && eval "$versioncmds"
unset PKGNAM SRCNAM
cd "$prevdir"
fi
in theory, yes. but as i pointed out: i don't know if you can trust the info files. the truth lies in the slackbuild
Is there any reason that makes you think the .info can't be trusted, and that the SlackBuild can be trusted? I'm only an amateur on SBo, but from reading this thread it seems to me that the safest update checking method would require:
checking for changes in the SlackBuild (any changes, not just the $VERSION or $BUILD, as I don't think $BUILD is necessarily bumped on script patches).
checking for changes in the .info file (specifically MD5SUM/MD5SUM_x86_64, VERSION, and REQUIRES).
I wonder if a viable method would be to create a checksum snapshot of the local SBo repo, and then recompute a comparison set when checking for updates. So for each program in the repo first checksum the SlackBuild (to pick up any future changes), and then checksum the contents of the md5sum, requires, and version strings in the .info file. That would give a lot of information about what has actually been updated, but it might be really slow, I don't know.
It might also be worth having a sanity check that looks for mismatches between the SlackBuild $VERSION and the .info VERSION (a slight extension of your method of scraping versions from SlackBuilds).
I like that you're building a source file and invoke that instead of trying to evaluate all the possible ways to set a bash variable in a sed script like I did it -- let bash do it !
I wonder if a viable method would be to create a checksum snapshot of the local SBo repo, and then recompute a comparison set when checking for updates. So for each program in the repo first checksum the SlackBuild (to pick up any future changes), and then checksum the contents of the md5sum, requires, and version strings in the .info file.
Dude, git exists
Quote:
Originally Posted by drgibbon
It might also be worth having a sanity check that looks for mismatches between the SlackBuild $VERSION and the .info VERSION (a slight extension of your method of scraping versions from SlackBuilds).
in theory, yes. but as i pointed out: i don't know if you can trust the info files. the truth lies in the slackbuild - the version saved in the slackbuild will be built, not the version in the info file.
it depends
Code:
VERSION=${VERSION:-0.1.2}
so it is actually the context of the thing that calls the script that has the ultimate truth :-)
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
Quote:
Originally Posted by dederon
to shed more light on this i will release sbog 0.2 soon (tm), which will extend the "sbog test" command. i didn't mention this command in my starter post, is it is meant to be used by repository maintainers.
in version 0.1 the test command parses every slackbuild in a directory for the package version and will print an error message if this fails. in version 0.2 sbog will additionally parse the info file and compare both package versions. then we know what we are dealing with and if the info files are in sync with the slackbuilds. still you need the slackbuild for the build number, which is not saved in the info file.
as i pointed out earlier, in the end it boils down to the fact that the package version is saved twice in the repository, which can lead to inconsistencies.
i write more once 0.2 is ready.
you do it right, implement one step after the other, as you think it fits best
@ponce: i have seen you applied my patches - thank you! after your changes are merged into master i can remove dianara from the list of unsupported packages. i will invest some time now to read more of the sbopkg code.
@kjhambrick: i agree with you about the info file, now i will see how sbopkg is exactly dealing with these files. i want to be sure. the problem of retrieving the version and build number from the slackbuilds is solved, as you can see in my starter post. thanks for your input, it helped a lot.
@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.
@a4z: you are right about the version. we will see once i learned more about sbopkg. i got a lot of input today to absorb.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.