[Debian-med-packaging] Comments regarding openmrs_1.6.1-1_amd64.changes

[Misha Koshelev]

Hi Mike et al:

Thank you so much for the clarification.

> I think the initial concern was that your upstream source contained
> .class files for which there might not be source files (.java files).
> If that is the case, the upstream source will need to be modified
> (either to omit the binaries for which source isn't included, or to
> include the source).

Fyi, I don't think removing the JAR dependencies is a practical option
for OpenMRS, especially in a version that has already been released.

Thus, your suggestion seems to be to include the source for all the binary JARs.

This seems like a great suggestion. However, I would appreciate any
hints on how to go about doing this...

Specifically, if I understand correctly the problem with tools such as
Maven is that, during _build_ time, network access is not allowed.

I don't believe that including all the source jars in the SVN repo
would go well with current OpenMRS devs. However, I don't see why they
can't be included in a Debian source deb...

Do I understand correctly that if I simply include code to download
JAR sources and, say, put them in a jar-sources folder, in
debian/orig-tar.sh, which is called from debian/watch by uscan, all
will be kosher?

Thank you
Yours
Misha

---

Please find relevant files below:

debian/orig-tar.sh

#!/bin/sh -e

# $2 = version
# $3 = destdir/$2
TAR=`echo $3 | sed s/$2//`openmrs_$2.orig.tar.gz
DIR=openmrs-$2.orig

# clean up the upstream tarball
svn export http://svn.openmrs.org/openmrs/tags/$2/ $DIR --quiet
GZIP=--best tar -c -z -f $TAR $DIR
rm -rf $DIR
rm $3

# move to directory 'tarballs'
if [ -r .svn/deb-layout ]; then
  . .svn/deb-layout
  mv $TAR $origDir
  echo "moved $TAR to $origDir"
fi

debian/watch

# explicitly avoid matching any versions that have a dash (-), such as
alphas/betas/release candidates
version=3
http://source.openmrs.org/browse/OpenMRS/tags/
/browse/OpenMRS/tags/([\d.]*) debian debian/orig-tar.sh


On Tue, Nov 9, 2010 at 6:04 PM, Mike O'Connor <stew at debian.org> wrote:
> On Tue, 9 Nov 2010 17:01:01 -0600, Misha Koshelev <misha680 at gmail.com> wrote:
>> Dear Luca et al,
>>
>> Thank you very much for your well thought out comment regarding the
>> JAR files. You are correct, the JAR files do indeed include .class
>> files, which are indeed binary artifacts.
>>
>  [ .. snip .. ]
>
>>
>> You will also note that existing Debian Java packages actually seem to
>> include such "binary" components in their source packages as well.
>>
>> One example, referenced by the Java Packaging team as a "good example
>> of up to date projects" is:
>> http://packages.debian.org/testing/misc/weirdx
>> (see http://wiki.debian.org/Java/ExamplePackages for reference)
>>
>> You will note that, if you browse the "source tarball":
>> http://ftp.de.debian.org/debian/pool/main/w/weirdx/weirdx_1.0.32.orig.tar.gz
>> there is a jar file with similar binary artifacts (misc/weirdx.jar).
>
> Perhaps you are misunderstanding the crux of the issue.  A source
> package including binaries is ok if it also includes the source for
> those binaries.  A binary package including binaries is ok if those
> binaries are build from source during the package build.
>
> I think the initial concern was that your upstream source contained
> .class files for which there might not be source files (.java files).
> If that is the case, the upstream source will need to be modified
> (either to omit the binaries for which source isn't included, or to
> include the source).
>
> I looked at the source package you pointed at, and at a quick glance I
> only see the one jar (misc/weirdx.jar), and it looked like the .java
> files also existed in the source package for the class files contained
> in the jar.
>
> stew
>