Spec URL: <http://villadalmine.fedorapeople.org/eatmydata.spec> SRPM URL: <http://villadalmine.fedorapeople.org/eatmydata-0.82-1.fc19.src.rpm> Description: Hi this is my first package and I want to someone give me a review of it in order to get this package ready. This package contains a small LD_PRELOAD library (libeatmydata) and a couple of helper utilities designed to transparently disable fsync and friends (like open(O_SYNC)). This has two side-effects: making software that writes data safely to disk a lot quicker and making this software no longer crash safe.. Fedora Account System Username: villadalmine
Why not name this package as libeatmydata? Just because other distros named it as eatmydata? Besides it's version number is 82, not 0.82, you should not use 0.82.
Yeah, @cicku are right, the package must be named like libeatmydata, since that is the upstream name, and change the version to 82 must to do a devel package, there are unversioned so files placed directly in %{_libdir} that isn't necessary for the end-users See http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages run ldconfig in shared libs https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Shared_Libraries rpmls eatmydata-0.82-1.fc20.x86_64.rpm -rwxr-xr-x /usr/bin/eatmydata lrwxrwxrwx /usr/lib64/libeatmydata.so lrwxrwxrwx /usr/lib64/libeatmydata.so.1 -rwxr-xr-x /usr/lib64/libeatmydata.so.1.1.1 -rwxr-xr-x /usr/libexec/eatmydata.sh drwxr-xr-x /usr/share/doc/eatmydata -rw-r--r-- /usr/share/doc/eatmydata/AUTHORS -rw-r--r-- /usr/share/doc/eatmydata/COPYING -rw-r--r-- /usr/share/doc/eatmydata/README - Please double-check the licenses cat licensecheck.txt GPL (v2 or later) ----------------- /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/libeatmydata-82/config/ltmain.sh GPL (v3 or later) ----------------- /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/libeatmydata-82/libeatmydata/test/eatmydatatest.c /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/libeatmydata-82/libeatmydata/test/eatmydatatest_largefile.c GPL (v3) -------- /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/libeatmydata-82/libeatmydata/libeatmydata.c /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/libeatmydata-82/libeatmydata/test/fsynctest.c LGPL (v2.1 or later) -------------------- /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/libeatmydata-82/libeatmydata/test/tst-cancel4.c - Description is too long, should be 80 character per line
Please remove NotReady from the Whiteboard when the issues in comment:2 are handled.
Hmm... I think you should ask upstream for a relicensing if needed.
I'd like to try and take over this package review request, I've updated the spec from Rino, spec : http://goodsquishy.com/downloads/eatmydata/libeatmydata.spec source rpm : http://goodsquishy.com/downloads/eatmydata/libeatmydata-105-1.fc20.src.rpm Fedora Account System Username: derekh
Yes, go ahead take it and follow the process, It's yours.. Regards
Please don't add this package to Fedora. I'm not sure exactly what problem you are trying to solve in this particular case, but this is almost certainly not the right way to do it. If you have a filesystem related performance issue with an application, then my team can help to advise on how to solve that, but ignoring O_SYNC and fsync is not the right way to do it.
The motivation behind this is to speed up disposable systems, for example it can be used to speed up arbitrary CI or Unit tests where data corruption following an error doesn't matter, the test is just rerun. In the specific example that prompted me to take over this review request, eatmydata greatly speeds up yum installs during CI tests and qcow image builds, if anything fails during either of these processes I would just rerun. I'm sure its possible to get a similar performance increase by tuning storage but for processes that can be run on arbitary systems it may not always be possible or practical to do the appropriate tuning.
FYI there already exist such SW in Fedora: https://apps.fedoraproject.org/packages/nosync
Thanks Miroslav I didn't know about nosync, I'm going to close this, it looks like nosync does the same thing.