@knurpht , when you say “remove packman”, is disabling effectively the same as removing (deleting) the directory. I don’t know whether something could not be read from a unenabled repo.
thanks, tom kosvic
That would do the same, but why would you have repos you no longer use
Your repolist is kind of messed up.
Repo 4 is packman essentials (disabled) and repo 13 is packman all (enabled).
So you still have packman enabled. Why do you have essentials and full packman? Essential is part of full packman and thus not needed at all when you have full packman.
But that is not the main problem. As Knurpht noted, the vendor change would work only on a stock system. You have to many external/devel repos, so you would break your system finaly by executing the vendor change…it would move many packages to your external repos…this can easily be seen at the output.
sorry, I saw that an requested message to be deleted.
My fault
@hui,
thanks for the observation regarding shifts to science, graphics, etc.
It is not done updating yet but I have a “timeshift” snapshot from early this morning. I will revert back to that rather than try to resolve a hundred problems.
I will let it be and leave packman installed.
tom kosvic
I use tumbleweed with --allow-vendor-change and it always goes back and forth between OSS and packman, but it never broke in the past >15years I’m using tumbleweed. Using flatpak has other disadvantages. And yes, without packman, I would miss essential functionality beyond vlc, wich includes not only codecs.
2 Likes
Generally speaking, that is not a good idea since you have no direct control on what is being installed, I wonder what “it never broke in the past” really means.
Using --allow-vendor-change while updating or installing specific packages is the way to go, that is install from Packman (or any other third party repo) only the minimum set you really need.
1 Like
–allow-vendor-change was just a shortcut expression for resolving those vendor change conflicts. Zypper asks me about them and has 3 suggestions per issue. That just works fine. I’m using the tumbleweed script to update.
1 Like
Like rigow, I use --allow-vendor-change as a way of resolving conflicts that pop up, and it’s not caused anything to break. I do review the list of what’s changing vendor carefully, and if anything looks like it might be a problem if it changes vendor, then I dig into it further.
1 Like
I’ve used zypper for years and Packman has never raised any issues. I’ve been reluctant to use flatpak or anything outside of the “standard” repositories. It’s a new learning curve. I’ll keep what I have for now. Can someone tell me, though, about the security of flatpak?
1 Like
Not worse than Packman.
@jonc You can enable “verified” only flatpaks via the --subset=verified verified option.
I avoid flatpak for one simple reason … I use plocate and locate "whatever" quite alot … when I install a flatpak and search for a string the output gets polluted with tons of “flatpak” output … if I uninstall that flatpak and do an updatedb then search the same string again I still get the same pollution of the results. I’ve checked to see if it was true and come to the conclusion that flatpak or discover doesn’t do proper cleanup
Maybe I’m wrong but in my case I just avoid it and stick with distro/zypper packages
1 Like
Can’t you just create an alias and exclude ~/.var? Or are they being installed as system flatpaks (bad idea…)?
Any flatpak I install (as user dart … I don’t install as root) is from discover so if there is a “bad idea” there it is because of a failure in discover
This doesn’t address the issue of flatpak not removing uninstalled packages or their confg dirs
@dart364 you need to look at the man page 
use the --delete-data option as well…
does discover do that by default? Because that’s how most users are going to install flatpaks … in my experience no
@dart364 not a Plasma users, sounds like you need to talk with upstream then… All my management is via command line here…