On Mon, Mar 23, 2020 at 11:47:58PM -0400, Scott Kitterman wrote:
> > If you can't fix postfix's flaky autopkg test, can you please revert the
> > explicit dependency on e2fsprogs?
>
> I've asked in #debci to see if they have any suggestions about the pty
> shortage on arm64.
Thanks; it looks like the CI folks have managed to fix the postfix
failure, so at least the short-term failure is fixed. The reason why
I was concerned was it looks like autopkgtest doesn't retry after
failures, so a maintainer that tries to add autopkgtests, in the face
of flaky CI infrastructure, is in effect punished for their attempt to
make things better, since it will significantly slow (or permanently
bar) testing migration --- no good deed goes unpushed...
> The dependency was added due to bug #887277. Do you not support the goal of
> making e2fsprogs non-essential at some point? While I realize dropping the
> dependency solves your particular problem, it doesn't actually make things
> more reliable.
I don't think making e2fsprogs non-essential is worth a lot of effort.
If it causes pain, my personal preference is to well, Not. Part of
that is I suspect there are plenty of (user/adinistrator) shell
scripts which use chattr, so just adding e2fsprogs as a dependency is
not going to make things more reliable *anyway*.
And there are plenty of other places where the size of debootstrap's
minbase size can be reduced (e.g., simply separating out the
translation files from a large number of packages, including
shellutils) will save a heck of al ot more space. So why not go after
the low-hanging fruit instead of inflicting pain on other maintainers?
If the CI infrastructure were reliable, I wouldn't care about people
adding dependencies on e2fsprogs. But when it isn't, then it just
drives home the point that trying to make e2fsprogs non-essential
isn't "free", and past a certain point, we need to ask whether it's
worth the effort.
> The only option used by postfix is S. Do you have a suggestion for an
> alternative approach that would not suffer from the same limitations? I
> inherited the current setup from lamont. I'm not personally wedded to it,
> but
> I think the function is important, but I'm totally open to alternative ways
> to
> achieve it.
So first of all, are you sure 'S' (S_SYNC) is what you really want? I
assume postfix, like most MTA's, will use fsync(2) as necessary to
guarantee file data are properly pushed out to disk when it is
necessary for reliability. And if you set the Sync flag on the
directory, it gets inherited by all files created in that directory,
which might not what be you want. What you might instead is the 'D'
(O_DIRSYNC) flag, applies only to directories.
If all you want to do is to set a flag, whether it's O_SYNC or
O_DIRSYNC, creating a small C program which basically does:
#include <sys/types.h>
#include <fcntl.h>
#include <sys/ioctl.h>
int fd, f;
fd = open(buf, O_RDONLY);
ioctl(fd, FS_IOC_GETFLAGS, &f);
f |= O_DIRSYNC;
ioctl(fd, FS_IOC_SETFLAGS, &f);
close(fd);
To clear the flag, just use "f &= ~O_DIRSYNC" instead. Or use O_SYNC
if that's really want you want.
It might be possible to use perl instead, but unfortunately,
sys/ioctl.ph isn't in perl-base, so unless you want to add a
dependency on libperl5.30 it just means adding another dependency
instead of e2fsprogs.
Cheers,
- Ted
