Re: OSCAR 10.12 has been packaged
Hi Peter,
On Sun, Jul 10, 2011 at 10:05:06AM -0400, Peter Hutten-Czapski wrote:
> I am uncertain as to your meaning as to what would happen if we
> packaged through you.
I would rather say 'us' instead of 'you' in the sentence above.
> Let me introduce myself a bit further. I am am an associate professor
> of medicine at the Northern Ontario School of Medicine who is
> volunteering his time to help package OSCAR, a project of another
> medical school McMaster. I, alas, have not been schooled as a
> programmer, so thank you in advance for your patience with elementary
> questions.
Thanks for the introduction - this makes communication a bit more easy.
> The timing of this communication is fortuitous. We are indeed at the
> moment going through policy and such to have ourselves placed in a
> repository. We picked Ubuntu as it is a common distro, I have hand
> written a simple .deb that we have tested and released at Sourceforge
> but have not yet made a .dsc
Thanks to your introduction I can guess what you did and I admit that we
have seen such approach in the past (too) frequently by packaging
newcomers. Debian has developed a lot of nifty tools to build Debian
packages quite simple. For some reason I fail to understand these tools
seem to be out of reach for newcomers and they tend to ignore these
while prefering to go the hard way and do things manually.
Experienced packagers start by creating a debian/ directory and place
some files (control, rules, copyright, ...) into this and than say
debuild (or similar or some of its friends). This automatically creates
a so called source package which consists of a *.dsc file and some kind
of diff-tarball which contains the debian/ dir mentioned above as well
as patches which might be needed against the original download tarball.
We tried to assemble the "Essential readings" to understand this in our
Debian Med policy[1] which is intended to help newcomers.
> git clone -b new_RELEASE_10_12
> git://oscarmcmaster.git.sourceforge.net/gitroot/oscarmcmaster/oscar
OK, this link works.
> 10_12 is the last version that compiles with ant. I have not tested
> if it compiles with maven, but it is supposed to.
>
> Our intention is to make OSCAR readily available to as many users as
> might like to give us a try through apt-get or its GUI equivalent.
So at least we have a common goal here: The Debian Med goal is to
provide *inside* Debian all free medical software which is used in
practice and might be relevant for medical care in some respect. You
obviosely consider OSCAR in this category and having it straight
packaged inside Debian makes it available for Ubuntu and its derivatives
as well.
> As OSCAR is a WAR binary that needs MySQL Tomcat6 and Java, its
> sufficiently abstracted from the architecture and the kernel, I suffer
> under the naive belief that it should not be hard to form a generic
> package that would work in most if not all Debian type distributions.
While the "would work" part is possibly true we usually are facing
problems cased by tha fact that Java packages tend to ship third party
binaries (JAR files) from other projects which makes it usually a bit
harder to include it into official Debian because we need to respect the
modularised packaging system ... and we need to provide the source for
all binary chunks - but lets dive into these details later.
> As our target distro is Ubuntu 10.04 LTS, it seems to make sense to
> continue our work there to be entered into the Ubuntu repository.
> Please explain why we would want to package with you, if that would
> make our work with Ubuntu void?
You probably know that Ubuntu is derived from Debian and if the source
where you are deriving from just contains what you want to add than you
are ready because the deriving process just includes what's inside
Debian. Does this make sense?
Now to the technical details after pulling OSCAR source. I had a
*quick* view into it. I have seen some JAR files (mentioned above).
For instance these are in the dir
HL7FileManagement/mule-1.3.3
While I'm no Java expert my guess is that we might have chances to replace
these by using the package libmule-java-2.0. Can you (or someone else
of your team confirm this?
I also found RourkeVacsMigrator/RourkeVacsMigrator.jar which comes
without source nor can I see a copyright statement.
I also found JARs in build/tasks/lib without source and copyright
statement. All in all the repository contains 290 JAR files and we need
to verify whether these can be replaced by just packaged libraries
inside Debian. If not we need to seek for the source of these JARs and
check the license. If we fail in doing so the last resort is to move
the package into Debian non-free - but the Debian main archive should
be our primary goal in any case.
If you might wonder how the cooperation with the Debian Med team works -
for instance to solve things like mentioned above - here are some basic
hints: In case you might have read the Debian Med policy[1] you might
have noticed that we are using a version control system to work together
with the packaging. It's basically about the debian/ directory and you
can either commit this into SVN. The Git people follow the strategy to
work on a clone of your repository and maintain debian/ in a branch. It
is up to you what you prefer (in case you would like to work together
with us).
It worked quite well in the past that Debian Med people worked together
with upstream to create proper packaging stuff - so just let us know if
you like this idea.
> Before printing, think about the environment.
I've thought about the environment - but why should I print now? I
never printed any e-mails. :-)
Kind regards and thanks for your interest in Debian Med
Andreas.
[1] http://debian-med.alioth.debian.org/docs/policy.html
--
http://fam-tille.de
Reply to: