I’m working in a new configuration of samba. If I don’t want to have problems with the new configuration (keeping parts of the old) I have to begin with a clean install. I removed the package, but the configuration files are still there. I would like to remove all samba related files, but it seems removing the package and installing it again does not clean all files.
Although I can list directories and files in the package and remove them by hand, I would like to know if there is a way to do it automatically (and with this package or any other).
For instance in debian apt remove removes a package but not the configuration files while apt purge removes the package and all configuration files. What I’m looking for is something equivalent to apt purge with zypper.
I do not know much about Samba (except that I tried to not install it on system installation), but in general:
Configuration files that belong to a package, but are in the domain of a user (mostly within ~/.local or ~/.conf) are not removed when the package is removed (and they are not created when the package is installed, at the most when the user uses them for the first time).
I also think that in he newer style of configuring, where the installation default configs are in /usr/share and the local to the system ones in /etc, those in /etc will not be removed (they are not part of the files installed with the package in the first place.
But of course not all software adheres (already) to the new ideas.
That in installation. Once running it creates new files and directories under this dirs… OK, i could use this list to rm all files and dirs, but I would like to know if it can be done automatically.
Your right, I"m sorry, did some googling and maybe try this, use the -f to force a reinstall that wont delete the old files but will over write them according to Google. Not exactly what your looking for but now I’m interested as well…
This will also not work. Force only reinstalls the files included in the package, but not the configuration files which are created after first start of the app.
I immediately will admit that I do not know anything about that tool (except that it is for software management in another Linux distribution), but I doubt it will be able to remove files (configuration ones or not) that are created by that software (or system managers, or users) when it is used beyond the files that are installed with the package (except maybe files created inside directories that were installed with the package by simply removing the directory)
Yes, thats it. It removes the package and all the system wide configuration, meaning all the configuration files and all the directories created by it, so if you purge a package and install it again you can fresh start configuration. It does not remove home user configuration.
But for what I’m looking for it seems there is no option similar with zypper. I think with a simple package, if you reinstall with --force and there is only one configuration file (typical /etc/program.conf the old file is keep as a backup and a new file from the package is installed, am I correct? but if it is a complex package like samba is, with configuration files in several directories and log files and databases created in different directories under its installation directories, there is no way but
-Remove the package
-Manually delete files and directories
-Install the package again.
I will not simply believe this. How can a package (de)installer know what files are created (configuration or not) during the life of the package? It only knows about files that are listed in the RPM.
It can’t know what the config files are, but it can know were they are located (except for home user configuration). As for samba, samba itselt says where they are:
No. You are talking about the specific case of Samba. I am talking in general (and that is what you did in post #1 above). A software management tool will not know if a package includes a specific command (with specific options) to provide such information. Try this for the package MozillaFirefox .
No, but it knows what files an directories are created during the installation of the package, and use this information to remove them all if asked to do it (apt purge vs apt remove in debian).
The config files created when used are stored in the configuration directories.
zypper rm does not remove them.
zypper in --force does not replace them.
apt remove does not remove them
apt purge does remove them.
I was looking for a similar option in zypper that the apt purge option. I see it is not there. It would be desirable it were.
Then this must have much additional information about what the software installed with a package might be able to create as configuration files. I doubt there is a feature in the RPM definition to facilitate that.
I also think that it requires a lot of manpower for the packager to gather and maintain that information from each and every package to be build.
Hmm… SailfishOS also uses or used zypper. There some users wrote bash scripts for that purpose. Maybe you (or somebody who knows bash scripting) can have a look at it to see if it might work in opensuse for you:
From the scripts shown there, you can detect that there is information to be get from the RPM
rpm -q --configfiles samba
But I am not sure if those are files created by RPM installation and marked as configuration files in the package or if they include extra configuration files created later (they could be there, they must not be there, but who knows?)
BTW, I would be very careful with the script itself. It also seems to check for certain files withing the home directory of one user (nemo) only, thus not for all users. And I personally would never meddle withing the home directories of any of my users.
Another BTW.
I have not seen any prove of what zypper rm removes. E.g. if it removes those files marked as “configuration files” in the RPM or not.
@fperal A lot of that is covered by the actual rpm install (eg %config (noreplace) or just %config), if the packager has configured it that way. Note that releases other than Leap are/have been transitioning to the /usr merge so anything (as it should) in /etc will not be touched as that’s for local admin to use and remember what they did…