Re: OSCAR 10.12 has been packaged
Hi Andreas
> 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.
==========
guilty
Using debuild implies that your source is structured for 'debian' and
you know what you are doing which both ours is, and I am, most
definitely not.
As you know you can use dpkg with a simpler "DEBIAN" structure with
hand built files and get something working. I am aware this approach
is perhaps a blind alley, and is too hands on to automate, but for a
complete novice like myself, is a proof of concept that (hopefully)
encourages the other.
I will look again at your debian med policy as I have only *quickly* skimmed it
>having it straight
> packaged inside Debian makes it available for Ubuntu and its derivatives
> as well.
=========
Then it seems that we can, and probably should, work together
> 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.
========
This makes it difficult. We have accumulated a large number of JARs
over the years (I do not dispute the 290 figure you quote) most of
which we still use :-), many if not most are specific to an older
version (e.g. the mule 1.3.3 we use for transport, you mention is
circa the year 2006 while the current mule project is currently at
version 3.1.0. Others such as HAPI we use to parse HL7, we have
updated to newer versions (0.6 circa 2009) although the current for
that project is 1.2). Because of this I fear that referencing
packaged libraries might be difficult. I will have to consult at our
next developer technical committee teleconference with the real
programmers as to finding the sources and the licences and if packaged
libraries will be possible/desired.
> 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.
=========
Again something that I am unable to or uncomfortable venturing an
opinion, and will refer to the developers technical committee.
Again thanking you for your help
================
Peter Hutten-Czapski
Haileybury Ontario
"The attitude that ‘if rural people want these services they’ll have
to come to the city to get them’ is simply not acceptable…” (Newbery,
1999)
Before printing, think about the environment. Avant d' imprimer,
pensez à l'environnement.
Reply to: