LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 02-18-2018, 08:42 AM   #16
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 4,661

Rep: Reputation: 1784Reputation: 1784Reputation: 1784Reputation: 1784Reputation: 1784Reputation: 1784Reputation: 1784Reputation: 1784Reputation: 1784Reputation: 1784Reputation: 1784

Quote:
Originally Posted by dederon View Post
sbog (like sbopkg) does not handle dependencies.

what are you trying to do? do you want the upgrades listed with regard to dependencies?
sbopkg can handle dependencies with the help of sqg which is included in the main package since 0.38.x
 
Old 02-18-2018, 08:57 AM   #17
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by drgibbon View Post
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.
 
4 members found this post helpful.
Old 02-18-2018, 09:25 AM   #18
drgibbon
Senior Member
 
Registered: Nov 2014
Distribution: Slackware64 15.0
Posts: 1,220

Rep: Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943
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.
 
Old 02-19-2018, 05:47 AM   #19
dederon
Member
 
Registered: Oct 2013
Posts: 108

Original Poster
Rep: Reputation: 56
Quote:
Originally Posted by drgibbon View Post
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.

i write more once 0.2 is ready.
 
Old 02-19-2018, 06:40 AM   #20
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 15.0 + Multilib
Posts: 2,159

Rep: Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512
Quote:
Originally Posted by dederon View Post
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.

-- kjh
 
3 members found this post helpful.
Old 02-19-2018, 07:07 AM   #21
dederon
Member
 
Registered: Oct 2013
Posts: 108

Original Poster
Rep: Reputation: 56
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.

your post was very helpful, thank you.
 
Old 02-19-2018, 08:04 AM   #22
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,098

Rep: Reputation: 4175Reputation: 4175Reputation: 4175Reputation: 4175Reputation: 4175Reputation: 4175Reputation: 4175Reputation: 4175Reputation: 4175Reputation: 4175Reputation: 4175
you can find more info in the git history (imported from the subversion one that was on googlecode): look in particular at the last commit's message

https://github.com/sbopkg/sbopkg/com...b63e216d39a32f

https://github.com/sbopkg/sbopkg/com...b9ca69f02ee6d9

https://github.com/sbopkg/sbopkg/com...08ede91990c3d9
 
Old 02-19-2018, 08:15 AM   #23
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 2,011

Rep: Reputation: 1619Reputation: 1619Reputation: 1619Reputation: 1619Reputation: 1619Reputation: 1619Reputation: 1619Reputation: 1619Reputation: 1619Reputation: 1619Reputation: 1619
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.
 
1 members found this post helpful.
Old 02-19-2018, 08:29 AM   #24
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 15.0 + Multilib
Posts: 2,159

Rep: Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512
dederon --

hoo boy ...

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
 
Old 02-19-2018, 10:01 AM   #25
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Code:
    # 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
Works for me ™
 
1 members found this post helpful.
Old 02-19-2018, 10:04 AM   #26
drgibbon
Senior Member
 
Registered: Nov 2014
Distribution: Slackware64 15.0
Posts: 1,220

Rep: Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943
Quote:
Originally Posted by dederon View Post
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).
 
Old 02-19-2018, 10:26 AM   #27
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 15.0 + Multilib
Posts: 2,159

Rep: Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512Reputation: 1512
Quote:
Originally Posted by 55020 View Post
55020 --

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 !

Thanks for the idea !

-- kjh
 
Old 02-19-2018, 10:44 AM   #28
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by drgibbon View Post
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 View Post
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).
It never hurts to validates your inputs [1] [2].
 
1 members found this post helpful.
Old 02-19-2018, 11:55 AM   #29
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742
Quote:
Originally Posted by dederon View Post
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 View Post
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
 
Old 02-19-2018, 01:39 PM   #30
dederon
Member
 
Registered: Oct 2013
Posts: 108

Original Poster
Rep: Reputation: 56
@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.

thanks for all your help, very much appreciated.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] sbopkg installs "original" SlackBuild to /usr/doc/<pkg>/ instead of "local" SlackBuild drumz Slackware 29 01-20-2018 12:12 AM
[SOLVED] [Sbopkg] - sqg generates wrong queue file for "linphone" joenew Slackware 11 01-06-2018 10:09 AM
[SOLVED] Can sbopkg "see" packages tagged something different that "_SBo"? solarfields Slackware 3 07-26-2015 06:03 PM
[SOLVED] Issues installing "shutter" SBo with sbopkg tallship Slackware 2 01-28-2011 01:29 AM
[ANN] sbopkg 0.33.1 released slakmagik Slackware 6 05-27-2010 10:02 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:32 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration