@pmatilai 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;
+       }

Returning FAIL here will fail the package install (which isn't pretty, but 
sometimes necessary). The exact semantics of when its okay to ignore failure 
are case-dependent and subject to debate and often practical experiences too. I 
think it's unreasonable to expect getting this 100% right from the go, consider 
this feedback more of a guideline than specific demands: silencing and/or 
ignoring an error should always be an exception to the rule.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r432348210
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to