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 suggest to wait until AlienBOB tested his KDE 5 on the latest current update
i'm pretty sure it would make some functionality to break due to many library soname bump in this batch.
only need to recompile some third party packages coming from SBo but that is normal so i won't be calling it an issue
It would be nice to have an easy option to track which of the installed SBO/3rd-party packages needs to be recompiled, or just
have an option Recompile in sbopkg:->Packages in addition to "List/uninstall installed"
At the moment I'm using the following script to do this.
I'm afraid that's not possible in a comfortable way, because (first thing that comes to mind) sbopkg has no idea which optional dependencies have you built, for example, ffmpeg against.
there's no automatic dependency resolution for stuff you built from SBo as they are not carved in stone, one can choose what to build what against (apart from the mandatory deps).
what I can tell you is that here, to avoid pain during these updates, I usually rebuild everything third-party I got on my current systems (I maintain a personal sbopkg queue for that).
*service message for SBo-git current repo users*: as here there's a huge comic convention in these days which I have to attend (lot of friends there) and the fact that this time I will have also to issue some updates to follow the gnome platform update (and more) will delay a little updates of my personal repo, I hope you will understand.
It would be nice to have an easy option to track which of the installed SBO/3rd-party packages needs to be recompiled, or just
have an option Recompile in sbopkg:->Packages in addition to "List/uninstall installed"
At the moment I'm using the following script to do this.
Ah, I forgot about sbbdep. I made a little script to check for broken libs: http://pastebin.com/fXh20kuH
Some packages however use libraries which cannot be found in the default paths and will appear broken, e.g. firefox.
Usage (e.g):
Quote:
./checkpkg /var/log/packages/*_SBo
Potentially broken packages will printed out.
Last edited by eldercitizen; 10-30-2015 at 05:46 AM.
I'm afraid that's not possible in a comfortable way, because (first thing that comes to mind) sbopkg has no idea which optional dependencies have you built, for example, ffmpeg against.
there's no automatic dependency resolution for stuff you built from SBo as they are not carved in stone, one can choose what to build what against (apart from the mandatory deps).
what I can tell you is that here, to avoid pain during these updates, I usually rebuild everything third-party I got on my current systems (I maintain a personal sbopkg queue for that).
*service message for SBo-git current repo users*: as here there's a huge comic convention in these days which I have to attend (lot of friends there) and the fact that this time I will have also to issue some updates to follow the gnome platform update (and more) will delay a little updates of my personal repo, I hope you will understand.
I agree with you, and the sbbdep mentioned below would not list all of the possible dependencies/conflicts.
> I usually rebuild everything third-party
I do more or less the same, except that I'm looking for a way to better organize my personal sbopkg queue.
BTW, I am not advocating the complete automatic dependency-resolving upgrade workflow.
I was thinking about an addition to the the sbopkg dialog interface, something like the attached sketch.
>*service message for SBo-git current repo users*:
Have fun at the comic con and thanks for the Slackware-current SBo git!
It would be nice to have an easy option to track which of the installed SBO/3rd-party packages needs to be recompiled, or just
have an option Recompile in sbopkg:->Packages in addition to "List/uninstall installed"
At the moment I'm using the following script to do this.
This little script will give you a rough idea:
Code:
#!/bin/bash
#
# depcheck.sh
#
# This script is a very basic dependency checker for Slackware Linux. It scans
# all the binaries in the PATH and reports any missing libraries.
for DIRECTORY in $(echo $PATH | sed 's/:/ /g'); do
for FILE in $DIRECTORY/*; do
if [ $(file -b $FILE | cut -d' ' -f1) == 'ELF' ]; then
if ldd $FILE | grep -q 'not found'; then
echo "$FILE"
ldd $FILE | grep 'not found' | awk '{print "Not found:", $1}'
fi
fi
done
done
You can download it here or grab it from my Github repo:
Ah, I forgot about sbbdep. I made a little script to check for broken libs: http://pastebin.com/fXh20kuH
Some packages however use libraries which cannot be found in the default paths and will appear broken, e.g. firefox.
Usage (e.g):
Potentially broken packages will printed out.
Thanks for the script! I'm going to look on how to modify it for my use, and perhaps by replacing 'ldd' with 'objdump -x | grep NEEDED' or sbbdep.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.