Hi, Without integration tests, linking Ceph against the wrong jerasure version may lead to data loss. Prior to publishing a Ceph version, various integration tests run to verify encoding / decoding, this is the main incentive to have jerasure as part of Ceph. The other reason is that jerasure can be optimized for SIMD instructions (ARM / INTEL) and not doing so significantly impacts performances.
Cheers On 08/07/2015 01:53, Thomas Goirand wrote: > On 07/06/2015 04:46 PM, Gaudenz Steinlin wrote: >> >> [ Adding the jerasure maintainer to the CC ] >> >> Hi >> >> Loic Dachary <l...@dachary.org> writes: >> >>> Hi, >>> >>> I'm co-maintainer of both jerasure and ceph. If the Debian jerasure >>> package was orphaned, I would be happy to step in and maintain it as a >>> standalone package. Jerasure was packaged without dialog with the >>> jerasure upstream and I can understand that keeping it in sync with >>> what ceph needs is significant work. >> >> Loic thanks for your offer to help with this. We definitively need some >> upstream assistence on this. IMO while the current approach to just use >> the bundled version is suboptimal, the previous approach to just >> unilaterally use a different version of jerasure than upstream is not >> good either. >> >> Currently ceph is AFAICS the only reverse dependency of jerasure. I >> don't know why Thomas packaged it in the first place. But if we want to >> keept the standalone package it might be the best for the ceph >> maintainers group to take over maintenance of the jerasure Debian >> package. I hope Thomas won't mind if we lower the burden for him a bit. > > I packaged it because it's needed by python-pyeclib, itself needed by > the latest Swift. No, I don't wish to hand-over its maintainership, but > I do accept contributions within the OpenStack packaging group on Alioth. > >> From a Distribution packagers standpoint the current situation is less >> than optimal. I would very much prefer to not have third party libraries >> bundled in the source code. But without upstream cooperation this is >> hard to solve, more so as the bundled library is also a modified version >> of the original jerasure code. > > Outch! Talking with upstream is indeed important here. FYI, I had to > battle the pyeclib upstream also, so that they don't embbed the package. > Having gf-complete and libjerasure early in Debian helped to convince > them, so I am happy I did the work early. > > Cheers, > > Thomas Goirand (zigo) > -- Loïc Dachary, Artisan Logiciel Libre
signature.asc
Description: OpenPGP digital signature
