I am aware that this question has been asked a lot over the years and I fully understand why the official recommendation of Slackware is to do a full install. In fact, I asked about this very issue a couple of years ago, but from a different viewpoint back then.

I understand that while Slackware defaults to installing everything, it is really secure because services are not started by default. You cannot compromise a service that is not running! I also appreciate that because Slackware does not manage dependencies like other distros, it's actually necessary to do a full install (to some extent) in order to ensure that everything works.

So I have no issue with the amount of space that Slackware takes up, nor any security concerns because services are disabled by default. I only install the following categories anyway as I use Slackware as a proxy Server for firewall and Internet Filtering. So I don't need games, Windows X or any gui.

A, AP, D, K, L, N

My practice is to update Slackware Servers every three months to ensure that things like Openssl, Openvpn etc are using the most secure versions.

What I have noticed is that Slackware is updating loads of programs like Samba, Rust, Ruby, Mozilla etc that are never ever used. All I have running on these systems is firewall, geoip (for firewall), forwarding, openvpn and a 3rd party program to filter Internet traffic.

I would like to reduce the amount of time I am waiting for the updgrade-all takes to update all packages by removing things like Rust that I never use. The updates take at least 20 minutes and I suspect three quarters of it are for programs that I never use and don't actually need for the purpose my Slackware distros are being used for. Rust in particular is a massive update!

Is it possible to remove any categories like D as I don't program anything. I do however use ./configure, make, make install to install the 3rd party internet filtering program and xtables-addons (for Geoip for firewall). The xtables-addons also requires some third party packages that use the perl Makefile.PL, make, make install commands. Other than that, I don't program or compile. So it would be ideal to get rid of the D category and only allow whatever is actually required to run make, make install. Do I need Rust, qt, Python, Mariadb, Ruby and LLvm for make, make install?

Qt5 also seems to take a while to update and reading up on it, doesn't seem like I need it. Samba, Mozilla - is not required for this server, so would be ideal to remove most of the N category

Looking at the size of the packages - I could probably remove the following without causing adverse affect:

Rust 876 Mb
qt5 382mb
llvm 368mb
mariadb 354mb
python3 136mb
samba 88mb
qt5-webkit 73mb
ruby 52mb
mozjs102 32mb

Hopefully just removing that, will speed up the updates, so I can get it down to say 5 minutes running upgrade-all.

I did try a couple of years ago creating a very slim lined base install of Slackware, removing loads of packages from the categories I used. Unfortunately I found that I was running into problems especially when updating Slackware as it was looking for various packages that I didn't realise that I needed. So I am not keen to go down that route again. I can't be forever spending time reviewing packages for dependencies. Slackpkg has a surprising number of dependencies on other packages!

But I would like to remove shall we say - the low hanging fruit such as Firefox, Samba and obvious packages that are only used if you actually use that feature. So would it be safe to remove the packages I have suggested above and would you recommend any others that can be safely removed eg Mutt, dovecot (as I am not running a mail server etc).

My goal is to reduce the upgrade-all time to around 5 minutes. Currently it takes at least 20 minutes to download and install packages running upgrade-all. I am not concerned about saving hard drive space or security concerns as explained above. My sole goal is to reduce upgrade-all running time by removing packages that are definitely not required.

I don't use slackpkg, so I don't know the answer to this question, but can you separate the downloading and upgrading steps? That is, set up a nightly (or weekly, monthly, whatever) cron job to only download new packages, and then upgrade them when you're ready? For most packages (I'm thinking kernel-source as 1 exception maybe) downloading takes significantly longer than actually installing/upgrading.

Also, I thought slackpkg had an option to only upgrade existing packages (and not install packages you don't already have installed). But once, I'm not a slackpkg user.

Also, I think slackpkg supports blacklists, so you could blacklist packages you don't want.

Those last 2 options might still download the packages, though, so you still might need to investigate the separate download/install steps.

Do you use Slackware-current on servers?

I'd just blacklist those packages in slackpkg

Marav - Yes I use Slackware Current. Does it make a difference to the question?

imitis - Instead of blacklisting those packages, a better solution is to uninstall them. slackpkg does not upgrade packages you don't have installed. My issue is what to uninstall/blacklist without breaking functionality.

drumz - That is actually not a bad idea - have a cron job that downloads the updates. This will cut the upgrade time in half. However the upgrade-all command downloads and installs the updates. Will need to see if I can split that. But I still would like to get rid of packages like Rust. I suspect Removing Rust alone will cut 2-3 minutes as that package is huge.

Rust has not yet been upgraded in slackware 15.0. It's still the original one.

slackware-current is the bleeding edge. There used to be a file slackware-current/CURRENT.WARNING:

In the future you could always install Slackware using Alien Bob's mini Slackware installer. It will install Slackware with the bare minimum of packages to get a useable system. After you install you could just install packages you need as you go. But be warned you really need to know what you are doing if you go this route.

http://www.slackware.com/~alien/slackboot/mini/

1 members found this post helpful.

Yes. It does
This directly answers the question

Running rolling-release, testing release, unstable release, or whatever is not "stable" release, should be avoided on servers
And Slackware current is all 3 at once

2 members found this post helpful.

Daedra - Yes, I am aware of Alien Bob's mini Slackware installer. However, I have gone down that route before, and found it was more trouble than it was worth to try and run a minimalist version of Slackware.

Petri - I was using Rust as an example of a big unnecessary package that is a waste of time to update. Not to indicate that I am getting updates of Rust that is.

I have found something that, while it does not address my question posted here, would actually reduce my need to update every 3 months.

Slackware Security Advisories - http://www.slackware.com/security

Looking at 2023, it would seem that there is very little that actually needs to be updated. I have two main reasons for updating. Security Updates (especially anything relating to the VPN, Openssl or the Firewall) and new functionality in programs that I use. So using 2023, I probably would only need to update four packages that I actually use - Kernel, Openssl, Openssh and Vim for the last three months for Security. Can't believe how few security updates are actually required for the last three months.

Then for functionality, just Openvpn and Openssl 3, to take advantage of DCO in Opevnpn 2.6.1. For some reason, I never noticed this security advisory page on the Slackware website before.

Then perhaps I can do a full update less regularly, maybe once a year? I presume that the rest of the updates in upgrade-all are just bug fixes, new functionality etc, so not really required unless you are experiencing a problem with a program you use or want a new feature in that program? My primary focus of updates is really security.

marav - I see we double posted. The reason that I use Current is because when I was running 14.2 I discovered that I was having problems with the Internet Filtering program. It turned out that 14.2 was still using Openssl 1.0.1 which was really obsolete by that stage, not to mention massively insecure. I needed at a minimum to run Openssl 1.1.1. I can't remember why running Openssl 1.1.1 did not work on 14.2, so I ended up going current. This is why I don't use the "Stable" version as I really need Openssl to be the most secure it can be.

I am aware that Current is not deemed to be best practice for running a production Server, but I have found Slackware Current to be rock solid reliable for me. I think if I just update the Security advisories of packages that I actually use or any Libraries, this should be sufficient to keep the server secure and just do a full update less frequently as I doubt the full upgrade is adding anything to security.

Rather than risk breakage or not having all the libraries Slackware provides/supports I prefer to run a home network. That way I can, in the somewhat rare instance it's needed, work on different hardware while the main one updates - no down time.

In reality these days, I tend to just go get a cup of coffee when updating or building a new kernel.

1 members found this post helpful.

Slackware Security Advisories are for stable releases of Slackware, not current.

And it sounds like you really want to run stable, not current.

Can you articulate why you need current instead of latest stable?

This is what I use on my very minimalistic slackware 15.0 VM:
My blacklist
e/
f/
k/
kde/
t/
tcl/
x/
xap/
xfce/
y/

drumz - It does specify Slackware 15 and Current. http://www.slackware.com/security/vi...ecurity.438114. I double posted with you earlier. In that post I explained why I run Current.

marav - That's basically what I have got. I don't install any of those categories either!

enorbet - I agree with you. Which is why I don't want to go down the route of too minimalist. More trouble than it's worth. I was just hoping to remove obvious packages that are definitely not being used that would reduce update time.

A better practice might be to upgrade a little more quickly when patches are published in the stable changelog. With packages from stable you will also be running versions known to be good, you will not be a beta tester of some upcoming Slackware version.

As said before, with Slackware stable only security patches will cause updates, this will save you some time.

Wihtout any packages from D you will not be able to run ./configure or make as both the tools called from the configure script and make itself are packages from the D series. If you need things like both gcc and llvm might depend upon which software your are going to install.

If you need those packages totally depends upon what you are going to install. However, with stable instead of current those packages are not upgraded very often.

For your purposes you might be able to uninstall samba, mariadb and qt5.

regards Henrik