Bugzilla – Bug 1158953
all files in /usr need to be owned by packages
Last modified: 2021-06-22 07:42:15 UTC
/usr (except /usr/local ) is the space for the package manager. All files there need to be owned by packages. This is to make sure the consistency of the system can be verified and no extra files alter the intended behavior.
I don't think this makes sense. If I install Nvidia drivers the hard way, that creates files that are not in packages. If I want to modify a text file (a configuration file or a script), I usually first create a backup ("filename.orig"). And that creates a file that won't be in a package.
(In reply to Neil Rickert from comment #1) > I don't think this makes sense. > > If I install Nvidia drivers the hard way, that creates files that are not in > packages. If I want to modify a text file (a configuration file or a > script), I usually first create a backup ("filename.orig"). And that > creates a file that won't be in a package. This is not the problem. User can install whatever they want onto their system by whatever means they desire. The problem is that our RPMs install files that are not owned by these RPMs, so removing the RPM would leave files behind. Furthermore, supportconfig should verify that user has not installed non-RPMs. We already check who provides that RPMs to make sure that user has a supported system. But we don't appear to check that the user installed via non-RPM method. And until we can install our RPMs properly (so files are owned by something), we can't even tell what the user has installed. All this is as valid for SLES as Tumbleweed as Leap. If users install something with `make install` or `cp` and they have problems because of this, then how do you even detect what is broken when we can't even tell whether file comes from RPM install or not? Files under /usr (outside /usr/local), /lib{,64}, /bin and /sbin should be owned by packages. Maybe we have exceptions for RPM for its database because of transactional server, bu that's about.
Thanks for that clarification. It now makes sense.
kernel weak-updates are not owned