Re: distributing precompiled binaries
Chow Loong Jin <hyperair@gmail.com> wrote:
>
> On Fri, 2009-03-27 at 11:24 +0000, MJ Ray wrote:
> > Chow Loong Jin <hyperair@gmail.com> wrote: [...]
> > > For the Python part, the sources are completely distributed, and no
> > > binaries are in the tarball. However, for the Java part, only the .jar
> > > is distributed in the tarball. I have contacted the upstream developer
> > > about this issue, and he will be releasing another tarball with the
> > > sources for the Java portion.
> >
> > I think this is a problem at the moment: DFSG 2 requires source code.
> That's fine, upstream will provide the source code in the next release,
> in addition to the bundled binary .jar
> >
> > > The problem begins here: The Java portion has a build-dependency on Sun
> > > Microsystem's WTK[1], and it is not free[2]. However, this is just a
> > > build dependency, and not a runtime dependency. In fact, the .jar isn't
> > > even supposed to run on the target machine, it's supposed to be uploaded
> > > to the mobile device.
> >
> > So this would be a practical problem, Fails To Build From Source, but
> > only for the mobile device component? I think the Java portion would
> > need to be in contrib at least due to the non-free build-dependency,
> > and probably non-free because presumably some bit of WTK ends up in
> > the jar file, [...]
> It wouldn't really FTBFS, if the mobile component isn't built, but
> instead shipped verbatim as a data file.
I'm not sure that it matters what you call the mobile component, if
that "data file" is really some sort of program that has sources which
aren't usable. How is that jar different from a PDF in this way?
[...]
> To summarize: Upstream will ship sources for the .jar as well as
> the .jar itself, but the .jar cannot be built from the sources without
> WTK, which is non-free, and cannot be distributed by Debian. So, I'd
> like to distribute the .jar as-is, without removing it from the upstream
> tarball, or rebuilding this .jar before distributing it. Is this
> permitted?
I don't think so, but I could be wrong. I'd remove the jar from the
remuco upstream tarball and aim to put it in its own contrib package.
> Also, as mentioned in debian-mentors, there is one such binary
> (not .jar, but .sis) which is distributed within the "gammu" package
> which is in main. Considering gammu's currently sitting in main, surely
> shipping the .jar similarly in remuco (the package I'm working on)
> wouldn't be a problem?
Does gammu give a justification? I don't see it considered in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180632
http://packages.debian.org/changelogs/pool/main/g/gammu/current/copyright
but there's a link to a gammu-legal post which isn't found.
I found gnapplet with sources in the contrib bit of the gammu tree.
https://buildd.debian.org/fetch.cgi?pkg=gammu;ver=1.23.1-2;arch=i386;stamp=1236036416
doesn't seem to mention it being rebuilt.
Can it not be rebuilt from those sources alone?
If it's a bug which has been overlooked, that's something else to fix,
not a reason for remuco to introduce a similar bug.
Hope that helps,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: