[SOLVED] Does slackware have a variant of "update-alternatives" or eselect?

Hello,

so Debian has update-alternatives, Gentoo has eselect, etc. That's how one would e.g. handle the iptables symlinks.

Does slackware have such a thing? Or should one use ln -sf manually here?

Like dependency handling, where I used some ldd, grep certain files etc.

thanks

Originally Posted by parse_flower Hello, so Debian has update-alternatives, Gentoo has eselect, etc. That's how one would e.g. handle the iptables symlinks. Does slackware have such a thing? Or should one use ln -sf manually here? Like dependency handling, where I used some ldd, grep certain files etc. thanks

BINGO!

You'll have to explain what you are actually trying to accomplish. You already have a mindset of how other distributions solve a certain problem, and then are trying to solve the problem in the same way in Slackware. Instead, ask what you are actually trying to achieve.

I'm not too familiar with update-alternatives or eselect, so I don't know for sure if Slackware has something similar. But I'm pretty sure it doesn't.

Perhaps this note from https://slackbuilds.org/repository/1...ies/wxPython3/ will help answer your question:

NOTE: wxPython3 can be installed alongside with wxPython, but it will overwrite some files created by wxPython. If you need to build packages using wxPython, simply reinstall wxPython package and wx-config will point to correct version. The same solution can be used if wxPython's wx-config is overwritten.

General answer is no, Slackware does not have them.

Were you trying to accomplish something specific that you would have used eselect or update-alternatives for?

/usr/bin/vi (could point to elvis, nvi, vim)?

Thanks LuckyCyborg, dugan,

so I think it's clear, and hereby explicitly "documented", that no such thing exists. That's probably in the spirit of Slackware.

If you came here searching for iptables symlinks:

#!/bin/sh

# switch iptables to "nft" backend, default is "legacy" backend
cd /usr/sbin
ln -sf xtables-nft-multi iptables-save
ln -sf xtables-nft-multi iptables-restore
ln -sf xtables-nft-multi iptables
ln -sf xtables-nft-multi ip6tables-save
ln -sf xtables-nft-multi ip6tables-restore
ln -sf xtables-nft-multi ip6tables

A word of caution. Even when there is no update-alternatives/eselect-workalike, the links may be silently undone when updating the iptables package. So I keep the script around, and maybe it should be run in certain situations, e.g. before running iptables commands.

Of course one could also write wrapper scripts and functions, and call iptables-nft directly from there. Note it seems docker and maybe other things call the iptables binary (whatever the link points to), so making the links makes sense.

drumz, why should one know about it, and why should anyone care?

First, because if you do these "ln -sf" commands, and something else wants to control these links, your work will soon be undone.

Second, imagine you do this on debian (just an example), not knowing about update-alternatives. And you open threads in a forum, trying to discuss your topic. If you get caught doing something "wrong" like that, the topic will certainly change ... For this, it is better to do things "right" to begin with.

What is update-alternatives/eselect?

So I think the more "full featured" distributions assume that /usr, /bin, /sbin, parts of /var and some other things are not for the user/admin to deal with, except for certain interfaces that have the distribution's blessing. For this, there are these tools that select default compiler versions (gcc, rust, llvm ...), select symlink targets for vi, iptables, others, select graphics related drivers and backends, and whatever. Just "eselect" in Gentoo, "update-alternatives --get-selections" shows more information about it. I'm sure Redhat, MX, Manjaro, Mint, Suse, Arch, deepin etc. have similar tools. Some more minimal ones might not.

Maybe I've missed something obvious, but I don't think there's any use for symlinks if one defines absolute paths within the iptables scripts.

Originally Posted by parse_flower So I think the more "full featured" distributions assume that /usr, /bin, /sbin, parts of /var and some other things are not for the user/admin to deal with, except for certain interfaces that have the distribution's blessing.

This is sometimes called policy, I believe that in Slackware it generally ends once you read and understand the license.
So far, my experience has been: Anything goes, break what you want and you get to keep the pieces, just don't complain later.
If you were the one who broke it, don't expect someone else to fix it.