Re: libsnappy (Was: Bug#662513: RM: emboss/6.3.1-6)
On Tue, Mar 06, 2012 at 02:09:22PM +0900, Charles Plessy wrote:
> > git clone git+ssh://tille@git.debian.org/git/users/plessy/snappy-java.git
>
> First, I confirm that the package builds well in a chroot (but not on my dirty
> machine).
Thanks.
> > 1. Create a fresh Git archive (in Debian Med) with the *changed*
> > upstream tarball?
> > 2. Inject the packaging into SVN
>
> I am neutral for the final location and container for the package. But maybe
> it would be best to have it in pkg-java (Git or Svn). Moving the Git package
> is the easiest, but using svn-inject is trivial.
While I agree that from a content point of view the package definitely
belongs to pkg-java. However, recently I injected some pure Java
libraries straight into Debian Med SVN (and I think others Olivier and
Matthieu did so as well with other libraries which are not specifically
related to medicine.) The rationale is that I consider it as a burden
to the other team (be it pkg-java or others) to move something into
their space and forget about this after the injection moving the
workload of maintenance onto their shoulders. Surely I could also
subscribe to their lists and become a member of other teams (I could
have been a member of pkg-java, pkg-perl, pkg-ruby and possibly some
ObjectiveC related team) but I think this does not scale well. So I
think that maintaining the package in our SVN which is writable for any
DD is the right way to go as long as no other team explicitly claims to
maintain it in their own spave.
> However, the main problem with snappy-java is not yet solved: it contains a
> convenience binary object for the “Snappy” C library, which means it is not
> free as it is. One possibility is to simply paste the source somewhere, but
> that is bad practice as it increases workload in case a bug is found is Snappy,
> and the other solution is to make libsnappy-java use Debian's snappy C library,
> which requires knowing about “JNI” and other things.
>
> This is where I would need help again.
This is solved with the get-orig-source target in debian/rules which
calls debian/get-orig-source. Do you have any problem with this
approach?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: