Comparing installed packages with the changelog...
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.
I think comparing installed packages with relatively vague format of changelog is not too reliable way. In root of repositories there are files named FILE_LIST containing all file names of the given repository so making a comparison with this list is IMHO a better idea.
For illustration purposes real example code of a small bash script using the above described fact follows. It's used for syncing patches of installed only packages. It even checks their GPG signatures and removes obosleted packages.
Code:
#!/bin/sh
# Syncpkgs - fetch updated packages from repository
# Repository URL with Slackware packages
MIRROR="http://<some.slackware.mirror>/slackware-12.0/patches"
# Directory where packages are stored
PACKAGES_CACHE=${PACKAGES_CACHE:-~/var/cache/slackware}
[ -d ${PACKAGES_CACHE} ] || mkdir -p ${PACKAGES_CACHE}
# Wheter to check gpg-signatures of packages
VERIFY_SIG="y"
# Create list of localy installed packages
FLIST_LOCAL=$(ls -1 /var/log/packages/)
# Create list of available packages in repository
wget -O ${PACKAGES_CACHE}/FILE_LIST ${MIRROR}/FILE_LIST || { echo "Error at fetching filelist !" >&2; exit 1; }
FLIST_REMOTE=$(sed -n 's/.*\s\.\/\([^\/]*\/.*\)\.tgz$/\1/p' ${PACKAGES_CACHE}/FILE_LIST)
# Fetch packages not yet in the local cache
for pkg in $FLIST_REMOTE;do
pkg_name=$(basename $pkg)
pkg_subdir=$(dirname $pkg)
pkgname_re='(^|\s)(('$(expr $pkg_name : '\(.*\)-.*-.*-.*$')')-[^-]*-[^-]*-[^-]*)(\s|$)'
if [[ ${FLIST_LOCAL} =~ ${pkgname_re} ]]; then
if [[ ! ${EXCLUDE} =~ ${BASH_REMATCH[3]} ]]; then
if [ ! -r ${PACKAGES_CACHE}/${pkg}.tgz ]; then
[ -d ${PACKAGES_CACHE}/${pkg_subdir} ] ||
mkdir -p ${PACKAGES_CACHE}/${pkg_subdir}
wget -c -O ${PACKAGES_CACHE}/$pkg.tgz $MIRROR/$pkg.tgz
[ $? -ne 0 ] &&
{ echo "Failed to download $pkg.tgz !" >&2; \
rm -f ${PACKAGES_CACHE}/$pkg.tgz; exit 1; }
fi
if [ ! -r ${PACKAGES_CACHE}/${pkg}.tgz.asc ]; then
wget -O ${PACKAGES_CACHE}/$pkg.tgz.asc $MIRROR/$pkg.tgz.asc
[ $? -ne 0 ] &&
{ echo "Failed to download $pkg.tgz.asc !" >&2; \
rm -f ${PACKAGES_CACHE}/$pkg.tgz.asc; exit 1; }
[ $VERIFY_SIG == "y" ] &&
gpg --verify ${PACKAGES_CACHE}/$pkg.tgz.asc &> /dev/null
[ $? -ne 0 ] &&
{ echo "Wrong signature for $pkg.tgz !" >&2; \
rm -f ${PACKAGES_CACHE}/$pkg.tgz*; \
exit 1; }
fi
fi
fi
done
# Remove all outdated packages - not available in repository
for pkgfile in $(find ${PACKAGES_CACHE} -type f -name '*.tgz'); do
if [[ ! ${FLIST_REMOTE} =~ $(basename $pkgfile .tgz) ]]; then
rm -f ${pkgfile}
rm -f ${pkgfile}.asc
fi
done
Yes. By early this morning it occurred to me to reverse the array (after I'd done it the hard way). And it simultaneously I also realize (most likely) what's happening is that hash key (and value) (keys must be unique) -- as in like or same key gets overwritten (for instance for the four versions of mkinitrd (the mkinitrd [due to like keys] key-value got overwritten four times) so that *only the last written* is the content that that particular key-value pair ends up with.
Am I on the trail now?
That's right. When we were looping, we checked to see if the key already existed in the hash, and if so we skipped straight on to the next line. With the non-looping method, the value will automatically overwrite if the key already exists, so we want to be sure that the "latest" version is the last to be processed.
As you are building your toolkit, take some time to look around CPAN. CPAN is the key to perl's longevity, with the thousands of utilities available so you don't have to reinvent any wheels.
I think comparing installed packages with relatively vague format of changelog is not too reliable way. In root of repositories there are files named FILE_LIST containing all file names of the given repository so making a comparison with this list is IMHO a better idea.
For illustration purposes real example code of a small bash script using the above described fact follows. It's used for syncing patches of installed only packages. It even checks their GPG signatures and removes obosleted packages.
I'm resurrecting this thread because I'd like to try this script and I'll report back on how it words for me.
I'm also interested in how the Perl script turned out.
Unfortunately too much on plate elsewhere keep (still) Perl script on the back burner.
I like to not use bandwidth unless it's necessary to do so. So, I'll likely use Perl and/or Perl calling Wget to check datestamp on the remote packages.txt (or changelog). If that file has not been updated since the last time that I checked that file means there are no new updates (end, done)
OTOH if that file has been updated -- now we can say yes updates available and have the script check and list what the new updates are.
BTW, of course, on the very first or initial run it would list what's available remotely that's not up to date on the sys (and record the datestamp of packages.txt (or changelog). Any subsequent run now uses datestamp method I mentioned earlier. datestamp check is fast and doesn't use much bandwidth except if updates are available then uses the needed bandwidth to check and say which/what list the updates.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.