Andrew Ayer: > On Wed, 26 Aug 2015 10:58:08 +0200 > HW42 <h...@ipsumj.de> wrote: > >>> Errors from close are not properly reported. >> >> Probably don't hurt. Most programs ignore them anyway. > > I think close() only fails if there's a disk error or you run out of > disk space/quota. Neither of these should happen during a normal build. > >>> fsync is not implemented. >> >> Beside of timing this should not make a difference as long the maschine >> don't crash. (I think that's what libeatmydata is doing via LD_PRELOAD). >> And we are building on tmpfs anyway (I don't know if fsync does anything >> on tmpfs). > > Right. To be clear, fsync() and fdatasync() still report success with > disorderfs - they just don't do anything. > >>> xattrs are not implemented. >> >> Probably only hurts for packages which need to handle those and have >> test cases for it. (e.g. rsync, rdiff-backup, ...) > > I'm guessing that only a minority of packages would be affected. > But, implementing xattrs turned out to be trivial, so I just released > 0.2.0 with xattr support. The Debian package is ready for someone to > upload.
nice. >> Can packages contain files with xattrs and if yes does this anybody? >> >>> Locks are not propagated to the underlying filesystem. >> >> This will hurt when a build system relies on them. I have no idea how >> many are affected by this. > > Locks still work within the overlay filesystem itself. However, if one > process is accessing the underlying filesystem directly, and another > process is accessing through disorderfs, they won't see each others' > locks. Since the build will only access through disorderfs, the lack > of lock propagation shouldn't affect builds. Ah ok. Then I think nothing _should_ break builds (with the updated version).
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproduciblefirstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds