I’m coming for a *deb/*buntu world and I would find useful if I have a cheat sheet for Tumbleweed with the most basic commands and especially if there is something that correlates them with commands I’m already familiar.
For example that
# zypper up
replaces # apt upgrade
I have already found a cheat sheet for zypper here https://en.opensuse.org/SDB:Zypper_usage#Cheat_sheet so I’m looking for something that includes more stuff than just zypper. Or is zypper the main difference? I mean (I’m completely new on opensuse) other stuff, like restarting services, or default location of config files, or how to do other basic low level actions, I’m not sure if they are different, but if yes, looking for such relation-map.
Hope it makes sense what I’m asking, thanks in advance
https://software.opensuse.org/packages for searching packages that aren’t in your activated repos, and steps to activate the one that contains them.
Thanks, I had a look and I wanted to ask even though it is kinda obvious but I want to confirm about the “community packages”. Who is building them? The word community implies that it may be a community behind them but the naming system suggests that they are personal repos (and most probably not checked). What is the case?
They’re repos maintained by a single person, and official documentation tells you to avoid them, cause their purpose is to be a place where maintainers can break unimportant stuff.
If something is only available through community repos, the official way forward would be to submit a bug report to OpenSUSE, asking to include the package in the official repo, or to contact the maintainer and ask them to do it.
I’d keep use of community repos to a minimum and prefer first flatpak, then the experimental repo over them. No one but the maintainer themselves checks or tests the community repos for stability and compatibility.
But I’ve activated one community repo for a package that wasn’t available anywhere else (sane-airscan).
I see. Yes, it is as I had suspected and yes, as there is not any guarantee that the package is legit unless you know the maintainer, then I also think it is better to avoid. Thanks for explaining