How to know when to rebuild own packages

Last week Pat updated glibmm.

Whilst rebuilding Inkscape, because of the recent upgrade to python3, I discovered that inkscape is dependent on glibmm. If the rebuild hadn't failed I would have never have known.

How do people, who build from SlackBuilds, know that they should rebuild certain packages when Pat upgrades a package in current/stable. I don't think any slackbuilds from SBO include in their requirements the packages that Pat supports.

Slackbuilds inkscape.info file has no mention of glibmm in it's requirements

PRGNAM="inkscape" VERSION="20191115_a4ee55b" HOMEPAGE="http://www.inkscape.org/" DOWNLOAD="http://ponce.cc/slackware/sources/repo/inkscape-20191115_a4ee55b.tar.xz" MD5SUM="0421027cbfdd89497b38ba1ce87a01b9" DOWNLOAD_x86_64="" MD5SUM_x86_64="" REQUIRES="GraphicsMagick gdl double-conversion lxml numpy potrace" MAINTAINER="Fernando Lopez Jr." EMAIL="fernando.lopezjr@gmail.com"

SBo doesn't list packages that are already included in Slackware, and one more note, it's designed to be tested against -stable release, which is 14.2 at this moment.

In general its less of an issue when running the stable version, and more common when running current, which is why running current is "at your own risk".

I try to use minimal third party packages on my slackware-current systems for this reason, and usually I find that somethings broken when I try to run it after updating and my terminal spews errors about missing libraries. You can also look at the changelog for version bumps to major shared libraries before updating to get an idea of what could break.

If you want to be a little more pro-active you could use a script to check for missing libraries. I had one bookmarked that one of the forum members here shared (hope you don't mine me linking this Orbea): https://notabug.org/orbea/SlackBuild...ipts/brokenpkg

This can give a clue:

#!/bin/sh
# Save me as deps_not_found.sh and run me as root
# This does only a very basic scanning. Caveats:
# 1. this finds only the missing binary files, not the missing python
#    perl, etc. scripts
# 2. There is not guarantee that for instance a header file includes the
#    needed definitions.
for i in $(find /usr/lib{,64} -name "*.so" -type f -executable) \
$(find /bin /usr/bin /sbin/ /usr/sbin -type f -executable); do
    if [ ! "$(ldd $i|grep found)" = "" ]; then
        echo $i
        ldd $i|grep found
    fi
done

SBo doesn't list packages that are already included in Slackware, and one more note, it's designed to be tested against -stable release, which is 14.2 at this moment.

While the long running argument for third party packages is a presumption of a full stock installation, listing those presumptive dependencies would be helpful. Informative and educational too.

That's a good educational way of asking people to do full installation on Slackware

slackyd -d

https://slackbuilds.org/repository/1...search=slackyd

Thanks for all the replies. All useful information.

For all my day to day work I use 14.2.

I do some testing on current, mainly to see if LibreOffice, mariadb and gnucash still work. There are always regressions that creep in - that's life. I'd rather find these regressions now. Anything else I find - like inkscape or like kde plasma a week or so a go is a bonus. I'm not finding any problems with Pat's or AlienBob's integration.

Testing is good. Hopefully, it will put me in a good place for the next release of Slackware.

How I mitigate on Current is that every so often I completely rebuild all the packages I've installed from Slackbuilds.org and a few others as well. This is not so much an issue on 14.2 as the churn rate is not very high and there are not many packages that depend on Thunderbird or Firefox!

I shall give the scripts a few trial runs, I expect I shall adapt them to my specific needs.

Thanks
Alex

Personally, I just wait until something breaks.

Another script:
chk3ppdeps