[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: Debian Packaging Drive

From: Allan MacKinnon
Subject: [Gnumed-devel] Re: Debian Packaging Drive
Date: Sun, 3 May 2009 21:53:56 -0300

Thank you for the prompt reply.  I'll Cc this response to the others on the gnumed-devel mailing list.

I understand the issue, even though it sounds like an inifinite regression: "How was the first GT.M made if you needs a GT.M to make a GT.M".  Out of curiousity can you tell me how such a thing is done?

Anyway, putting the GT.M deb in your account may be a good idea if that isn't the source of your bandwidth issue (never had a bandwidth cap issue come up for me yet on  The technical/administrative details with the Debian people can be worked out later as they examine the package and so forth. 

Also, the Hilbert Brothers who run the GNUmed project would likely want to see GT.M because they are looking for a billing backend for their program.  I think they are tooling around with FreeB right now but I'm sure they would be interested in looking at your work.

Plus, I'd also like to sample your EMR on my system and prefer to use DEBs if the software requires compiling.  From the sound of it I wouldn't know where to start to get GT.M compiled anyway :P

Stay in touch

On Sun, May 3, 2009 at 8:43 PM, K.S. Bhaskar <address@hidden> wrote:
Thanks for writing, Allan and thanks for your interest.

I did have a discussion with some Debian folks a couple of years ago.  It takes an existing GT.M binary to build GT.M - i.e., it is bootstrapped (not unlike gcc- you have to have a gcc in order to compile a gcc).  They understood the issue technically, but didn't seem comfortable with the idea.  So, GT.M probably can't be pushed up to the Debian repositories.

In any case, I do plan to package GT.M as a .deb file myself, but I'm probably about a month away from having the bandwidth to do so.

-- Bhaskar

reply via email to

[Prev in Thread] Current Thread [Next in Thread]