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.
Slackware is expected to be fully installed. You might run in dependencies troubles unless being very careful removing packages...
Indeed. The idea that dropping random packages (or even carefully selected packages) will "save me a lot of time updating -current" is not likely to be correct.
Some of us still enjoy using a more minimal install and being able to remove and recompile packages as needed is a great learning experience. Sure it may not make much difference in system upgrades except for potentially complicating them and hard drive space is not a concern for most people, but benefits in learning how your system works are well worth it.
On my system I use this script I found in an old arch forum post and modified slightly for slackware to make sure I did not remove anything important or to track down what extra packages need to be recompiled after an update. It works for my use case, but it probably needs a little work to be made more portable.
Code:
#!/bin/sh
# 2004/08/22 K. Piche Find missing library references.
# 2015/11/27 orbea Refreshed script
ifs=$IFS
IFS=':'
ARCH=$(uname -m)
libdirs="/lib:/usr/lib:/usr/X11R6/lib:/usr/libexec:/usr/$ARCH-slackware-linux:/lib64:/usr/lib64:/usr/X11R6/lib64"
extras=
# Check ELF binaries in the PATH and specified dir trees.
for tree in $PATH $libdirs $extras
do
echo DIR $tree
# Get list of files in tree.
files=$(find $tree -type f)
IFS=$ifs
for i in $files
do
if [ `file $i | grep -c 'ELF'` -ne 0 ]; then
# Is an ELF binary.
if [ `ldd $i 2>/dev/null | grep -c 'not found'` -ne 0 ]; then
# Missing lib.
echo "$i:"
ldd $i 2>/dev/null | grep 'not found'
fi
fi
done
done
exit
For comparison here is my customized /etc/slackpkg/blacklist
OT, but orbea, you may want to add bluez-firmware to that list Somehow we missed it for several months, so the very early versions of the list omitted it.
Yes, the trimming procedure can be time consuming and is unsupported. I could have full install on my build machine, but not on my netbook, where I can only spare 3,5G
Problem is when I compile something on full install, makefile will sometimes autodetect, and then depend on wide variety of things that don't exist on netbook.
So one could say trimming does save some time in the long run, because packages build much faster on desktop, and I won't have to define deps manually if the two systems are identical.
I'd say stable 14.1 is a much better target for discarding packages, because -current requirements change all the time.
These are just some of the things I build custom for both -curent and stable:
So far only GNU IceCat is a pain to compile, because with the exception of zlib, it's building it's own separate libs and this takes hours.
Apart from that small inconvenience, and kde being a standard tentackled freedesktop mess, it all works nicely on top of 2G base system with X.
I'm not fussy about removing packages as I used to be. I still dump sendmail though, most of the text editors, and am leaning away from KDE in favour of XFCE.
I certainly wouldn't recommend anyone remove stuff willy-nilly, but there's a fair amount of duplication of tools.
OT, but orbea, you may want to add bluez-firmware to that list Somehow we missed it for several months, so the very early versions of the list omitted it.
I don't have bluez-firmware on my system, it seems blacklisting just bluez is enough to get rid of both bluez and bluez-firmware.
You might run in dependencies troubles unless being very careful removing packages...
For example I removed yptools. I also removed a couple that were for mt. Does anyone hear even remember what mt stands for? I chuckled with nostalgia when I found those.
I also removed any that were for KDE.
BTW How many does ls -1 /var/log/packages|wc -l does your -current show?
On my system I use this script I found in an old arch forum post and modified slightly for slackware to make sure I did not remove anything important or to track down what extra packages need to be recompiled after an update. It works for my use case, but it probably needs a little work to be made more portable.
I will look at this script. I haven't used the blacklist feature as you have. This makes sense to do it this way.
Another question, can't you just comment out the SBo mirrors so ou don't get those packages?
Also Orbea is a high-end bike maker in the Basque country of Spain. Not that well known by most.
At least that is how I know the word orbea.
What I really need is to have a monitor watching the system and creating a list of files that have been loaded/used in the last 6-8 months or so.
Does anyone know if such a monitor exists? I was thinking back to tripwire or something like that.
Yeah, some file-based IDS would do it. The way you describe it, it seems similar to what OpenBSD's security(8) script would output; perhaps worth checking out and refit for Slackware.
The other way to achieve some minimalism here would be to start from a base list of packages (e.g. something like what I did for building my Docker slackware image and add the packages you need, instead of pruning from a full Slackware install.
Last edited by zakame; 01-20-2016 at 07:20 PM.
Reason: typo
Yeah, some file-based IDS would do it. The way you describe it, it seems similar to what OpenBSD's security(8) script would output; perhaps worth checking out and refit for Slackware.
I will have a look at that. It has to be something that's not obtrusive and adds very little or no overhead to be useful.
Quote:
The other way to achieve some minimalism here would be to start from a base list of packages (e.g. something like what I did for building my Docker slackware image and add the packages you need, instead of pruning from a full Slackware install.
Is docker using containers? I have sworn off them until they are actually working as described in the docs. Which may be never.
Well, we still have DAT and LTO tape drives, so the magnetic tape (mt) packages are still relevant here.
I guess it's a viable option still. Has the technology changed at all? i.e. data densities, materials, speed, etc.?
I wish I had a DAT drive still. I have some data on DAT but no drive. Will have to take them somewhere.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Somehow we missed it for several months, so the very early versions of the list omitted it.
