On Wed, Apr 03, 2013 at 04:04:24PM +0200, Christoph Egger wrote: > So what do you suggest as a solution for an debian-independent ar > module *right* *now*? I don't care specifically about arpy or whatever > else as long as it can a) handle compressed ar-s and b) is > vendor-neutral. arpy seems to provide both and I am currently not aware > of any (reasonable) alternatives.
Work with upstream to address the remaining issue. There already are way too many incomplete implementations. Similarly I had to put packaging python-ssdeep on hold, because the upstream software has too many severe issues. Not every software on the planet is worth including in Debian as is and arpy needlessly fails at a very basic task. The main problem here is that as far as I can see the API will have to change in order to address this legitimate use case. Once a library has larger adoption, changing it is harder and this issue will never be fixed. Better do it now before exposing in Debian. I even provided a proof of concept for how to do it. Failure to insist on getting this right will just result in multiple ar parsing libraries. I imagine that one version can read all the variants, another one can read from stdin, a third one can write. This is a disservice to our users and wastes resources (especially in package lists). So maybe we can work on a solution here? I'll try to patch arpy to support this use case. Give me a week? Helmut -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403142743.GA30587@localhost