RPM removal does not remove delivered dirs and leaves garbage

I deliver an application via an RPM.

This application delivers various directories and files.
E.g. under /opt/internal/com
a file structure is being copied.

I was expecting that on rpm -e all the file structure delivered under /opt/internal/com will be removed.
But it does not.
There are directories in the file structure that are non-empty.

Is this the reason? But these (non-empty) directories were created by the RPM installation. So I would expect that they would be "owned" by RPM and removed automatically.

Is this wrong? Am I supposed to remove them manually?

RPM won't delete any files it doesn't know about, so if new files have been created in a directory that are not part of a package, RPM won't remove them, or the directories.

It will delete the directories if they are empty and it knows about them. It depends how the spec file was written.

Answer from James O'Gorman is absolutely right.

One more scenario to add, which I recently encountered, is you need to tell directories owned by RPM package in %files section with a line "%dir /dir/path", so that it will remember all files and directories in RPM database when installed and can be removed (unless contents of the dir not own by that package) during RPM erase.

More care should be taken while specifying owned directories as there is different methods to process RPM erase on different distros.

e.g. if your package contains following files & directories:

**DIR:** /opt/dir1/empty_dir **FILE:** /opt/dir1/file1 **FILE:** /opt/dir1/dir2/file2

then your %files section should look like

%files
%dir /opt/dir1
%dir /opt/dir1/empty_dir
%dir /opt/dir1/dir2
/opt/dir1/file1
/opt/dir1/dir2/file2

Tricky part is, you might miss %dir /opt/dir1 and it won't be removed even if it is empty on some distros.