@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:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431905174
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
