@jessorensen commented on this pull request.

> +         rpmlog(RPMLOG_DEBUG, "fsverity not supported by file system for 
> %s\n",
+                  path);
+           break;
+       case EOPNOTSUPP:
+           rpmlog(RPMLOG_DEBUG, "fsverity not enabled on file system for %s\n",
+                  path);
+           break;
+       case ETXTBSY:
+           rpmlog(RPMLOG_DEBUG, "file is open by other process %s\n",
+                  path);
+           break;
+       default:
+           rpmlog(RPMLOG_DEBUG, "failed to enable verity (errno %i) for %s\n",
+                  errno, path);
+           break;
+       }

> Ignoring on unsupported filesystems is totally fine, that's exactly what we 
> do for SELinux (which is not supported on all filesystems either). There 
> might well be other specific errors where ignoring is the right thing to do, 
> but in general errors should be treated as such and fail the install, or at 
> least issue a warning that something might not be okay.

OK, excuse my ignorance here. If I return RPMRC_FAIL for these, will it fail 
the installation of the package, or just spew warnings? I didn't want to get 
into a state where I had to check the file system for each file, before I 
enabled verity on the file.

Do you prefer I return RPMRC_OK if it's not supported, but RPMRC_FAIL if it 
actually fails? I'll have to have another look at all the return values to make 
sure I have them covered correctly.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to