Re: OSCAR 10.12 has been packaged
On Sun, Jul 10, 2011 at 02:18:49PM -0400, Peter Hutten-Czapski wrote:
> 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'
What do you mean by "structured for 'debian'"? The packaging system can
cope with any structure of the source tarball and is able to sort
installation files wherever you want. I wonder from what information
source you migh have heard something else.
> 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.
This "DEBIAN" structure is not "simpler" it is rather intended as a dpkg
internal format and should not serve as API to build Debian packages.
> 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.
As I said - we would be happy to help.
> 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
Fine.
> > 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)
I'm not picky about this number - it was just a result of
find . -iname "*.jar" | wc -l
> 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.
That's what I mean: Putting some files straight into a deb archive is
cheap. Making packages fit into the system is the harder part. But we
might consider a two step approach: First moving a package to non-free
including the JARs and then continue working to get it really clean
for main.
> 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.
Reducing the number of JARs by sorting out what is not used might be a
good idea.
> > 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
It's a pleasure to work together with people working on free medical
software.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: