[Ignacio, I hope you will not mind if I'm answering your mail in
public shamelessly violating the netiquette, but I can not find
any private information in it and see a certain number of people
on the list who might be interested.]
On Thu, Jul 15, 2010 at 09:40:38AM -0500, Ignacio Valdes wrote:
> You may remember me from Linux Medical News.
Thanks for this service by the way.
> I have a apt-get/yum
> installable version of Veterans Affairs VistA called Astronaut VistA
> Installer Suite. Thousands of hours of preparation have gone into it.
> It is a reference implementation of the VistA Standard Base
> specification. It includes Astronaut editions of both OpenVista and
> WorldVistA in a common framework. It is tested in actual clinical
> situations and has many essential parts for private-sector use that
> are not currently present in other distributions. If you could include
> them in your debian-med distribution or a default pointer to the
> Astronaut apt-get repository http://software.astronautvista.com/deb > that would be great.
I would love to place a hint at the Debian Med tasks page for hospital
information systems at
You don't have permission to access /deb/ on this server.
For the official inclusion into Debian: To include a package you need
to be able to build the package from source which in the case of VistA
means we need to packahe GT.M (Mumps) first - you are probably much
better informed about this than me. Bhaskar did some effort on this in
the last time [1-3] but it is not finished to my knowledge (Bhaskar, I
was about to ping you about this again and I'm just using this thread
which seems to fit).
So I have no idea in how far we might base on your (Ignacio) work to
proceed with the Debian packaging but in any case it would be
interesting to know that there is something out there as an intermediate
solution or as a template for Debian policy compliant packaging. If
you have further ideas how we might be able to speed up things - we
are interested in any case.
I would be really happy if you would subscribe to the Debian Med mailing
list (in case you are not yet) where we try to discuss issues like
this. In any case we hope to provide news for your Web service from
time to time (like for instance FreeDiams will be included in next
official Dbeian release or something like this.
where the Vcs link (botom right in the yellow metainformation part) is
pointing to the locations above. If you think this makes sense it is
OK, otherwise please tell me what you would like to enhance (I'm not
completely happy with this not so visible link - but that's our usual
way to point to the packaging Vcs).
Great. I will have a look into your files tomorrow and will discuss
them on-list. I admit I do not really see there the usual packaging
stuff as we know it from normal Debian packaging - but perhaps I can
make up my mind tomorrow.
On Mon, Jul 19, 2010 at 02:21:03PM -0500, Ignacio Valdes wrote:
> Bhaskar, For what it is worth and there are certainly other ways of
> doing it but the Astronaut specific one is a very light wrapper of the
> configure script that comes with the pre-compiled gt.m. The
> etc/env.<branding> file scheme that Astronaut uses could be used by
> gt.m to parameterize installation.
While I consider the astronout solution a reasonable workaround for
official Debian packaging we need to compile (and thus find some
bootstrap mechanism) for GT.M.
> On Mon, Jul 19, 2010 at 2:07 PM, K.S. Bhaskar <[hidden email]> wrote:
> >> I have a apt-get/yum
I tried to make up my mind about the links you gave but I can not really
match this to the usual Debian packaging I know. Is it by chance that
you are using some tool which "magically" creates debs and rpms from one
source which is not really a Debian source package? Otherwise I can not
see how you might obtain Debian packages by using pure Debian packaging
On Mon, Jul 19, 2010 at 03:07:00PM -0400, K.S. Bhaskar wrote:
> [KSB] I have personally not had the bandwidth to create GT.M Debian
> packages. However, there are at least three, and perhaps four, Debian
> packages for GT.M that I know of. However, none of them is accommodates
> the full generality that GT.M requires. I have currently taken apart
> and am looking over two of the packages and will provide feedback in the
> next week or so to the packagers, and perhaps encourage them to pool
I would *really* welcome it if we would be able to assemble these
attempts under the Debian Med umbrella and move the packaging stuff
to the Debian Med SVN. For me the last status mail from you was,
that you changed the installation routine of GT.M in a way that
you are able to configure the installation target dir (which is
needed to build a Debian package. Is this realised now and can
we base on this release with the packaging?
> I hope this helps. We are moving forward, only not as fast as any of us
> would like.
As always - but that's no real problem. IMHO we will miss the next
Debian release (Squeeze) anyway - but that's no real problem - I think
it is fine if we might put GT.M and VistA into Squeeze+1.
Thanks for your input and please do not hesitate to ask packagers to
join us on this list and on Alioth.
On Mon, Jul 19, 2010 at 05:33:02PM -0500, Ignacio Valdes wrote:
> Do you mean that I would have to use tools like Alien?
No, on the contrary.
> Are their
> required tools to create both rpm's and deb's from the same source
> set? I simply did bash script sed type pre-processing that is on the
> launchpad.net site in their entirety to make them both work from the
> same source.
You need to use dpkg-buildpackage (or its wrappers debuild or better
pdebuild) to build the package (see Developers Reference ). Looking
there id no rules file, the control file is invalid and the postinst is
dealing with "/opt". I have no idea what to do to get a Debian package
from the files you provided. The default way to build a Debian package
using the tools mentioned above leads to a Debian source package
containing a *.dsc file and a file which contains the diff against the
upstream source (in source format 1.0 it is diff.gz in 3.0 it is
debian.tar.gz). We need to create these files using the normal build
process to upload to the Debian archive and the content inside the
package needs to be in /usr not /opt and not /usr/local or something
I would love to cooperate with anybody who is willing to do this work
and has some (at least basic) knowledge about GT.M (which I do not have).
Without having actually looked, the control is probably not invalid, but
just the binary package version of it, i.e. what you get during package
build in debian/$package/DEBIAN/control, and which ends up in the .deb
and /var/lib/dpkg/status after installation. Assembling a binary
package directly without a debian/ source directory seems to be done by
a couple of upstream people for one reason or the other, it is not the
correct way to do it in Debian, though, of course.
On Tue, Jul 20, 2010 at 08:40:10AM -0500, Ignacio Valdes wrote:
> > there id no rules file, the control file is invalid and the postinst is
> > dealing with "/opt". I have no idea what to do to get a Debian package
> > from the files you provided.
> How about the bash script called build_gtm.sh that is at the link above?
Well, we probably have different opinions about what a Debian package
is. In "my world" a Debian package is something where you compile a
program from source, install it to a temporary directory and build a
package from there. Your script just does the last part somehow.
Finally the resulting Debian package has to pass a lintian test.
> How would it deal with rpms then?
We were talking about building a package which is provided from the
Debian mirror as official Debian package which will be provided on
official Debian CDs^WDVDs^WBlueray disks. There is no need at all to
provide an RPM package from there because Debian does not provide any
> The above would seem to heavily tie
> it to Debian tools while not helping with rpm?
Well, it is the *Debian* Med project, isn't it? It has this name
because it is a Debian Pure Blend (=*internal* Debian project). It was
never intended to support RPMs and I wonder why you assume it should.
This does not mean that we would not seek for contact to Fedora or
OpenSuse and there are actually two mailing list which have a similar
goal (but no traffic on this list). I have contacted the people who
initialised these lists but there was no real response and so the chance
for cooperation is limited for the moment. There might be chances that
Fedora or OpenSuse users might profit from our work and I would try to
support this - but I personally have no idea about RPM.
BTW, I now understand your question about alien: Yes, once you have
builded a real Debian package you might use alien with good chances
to get a working RPM package.
> build_gtm.sh finds out
> what type of system it is on and builds a deb or rpm accordingly. That
> way if the whole thing is pulled you just run the script on the type
> of system it is on and it works.
But this is not intended. If we provide official Debian packages you
just know on what system you are.
Am Dienstag 20 Juli 2010, 17:06:02 schrieb Andreas Tille:
Just my 2 cents on this. I am with the GNUmed project and we have
> On Tue, Jul 20, 2010 at 08:40:10AM -0500, Ignacio Valdes wrote:
> > > there id no rules file, the control file is invalid and the postinst is
> > > dealing with "/opt". I have no idea what to do to get a Debian package
> > > from the files you provided.
> > How about the bash script called build_gtm.sh that is at the link above?
> Well, we probably have different opinions about what a Debian package
> is. In "my world" a Debian package is something where you compile a
> program from source, install it to a temporary directory and build a
> package from there. Your script just does the last part somehow.
> Finally the resulting Debian package has to pass a lintian test.
What we as upstream don't understand is why in bloody hell there are different
package types for different distributions. But so it is. Once you accept that
fact you as upstream want to have nicely integrated packages so the fit well
with a Linux distribution. Even if I dislike the fact that there is rpm, deb
and whatnot I have come to accept that is makes sense to package for each
distribution. One reason is that a lot of errors are prevented by the tools
used for building the package and second is that that way the files go to the
correct location for that distribution. Let me tell you if you want your
software to be used by many linux users (if you target them) then Debian is
your best choice. That way you will get into Ubuntu as well. Ubuntu is one of
the most visible distributions out there. While packaging is done for Debian
(which we very much welcome) most reports we get from people on Ubuntu.
I personally package for multiple rpm based distributions but I am not aware
of a substantial userbase. Long story short. If you want to see you software
included in Debian and Ubuntu you need proper packages.
> > How would it deal with rpms then?
> We were talking about building a package which is provided from the
> Debian mirror as official Debian package which will be provided on
> official Debian CDs^WDVDs^WBlueray disks. There is no need at all to
> provide an RPM package from there because Debian does not provide any
Exactly. If you want RPM packages for Fedora/Redhead Enterprise or
openSUSE/SUSE Enterprise you need proper packages for these. You willl have to
use their tools (e.g. openSUSE build service) and you can carry over a lot of
nifty stuff from Debian packages.
> > The above would seem to heavily tie
> > it to Debian tools while not helping with rpm?
> Well, it is the *Debian* Med project, isn't it? It has this name
> because it is a Debian Pure Blend (=*internal* Debian project). It was
> never intended to support RPMs and I wonder why you assume it should.
> This does not mean that we would not seek for contact to Fedora or
> OpenSuse and there are actually two mailing list which have a similar
> goal (but no traffic on this list). I have contacted the people who
> initialised these lists but there was no real response and so the chance
> for cooperation is limited for the moment. There might be chances that
> Fedora or OpenSuse users might profit from our work and I would try to
> support this - but I personally have no idea about RPM.
> BTW, I now understand your question about alien: Yes, once you have
> builded a real Debian package you might use alien with good chances
> to get a working RPM package.
Your goal should be to get your software into Debian/Ubuntu and RPM-based
distributions. It makes no sense to try to avoid that by using tools which try
to be smart and avoid the double packaging effort.
If you just want packages that might be possible but if you want distributions
to accept these there is no way around it.
Regarding other mailing lists. I am involved in the openSUSE medical project
and the Fedora medical SIG. The Debian-med group is much further in terms of
packaging. The openSUSE medical group has not gained much traction yet and
there is only one packager as far as I know. The Fedora group seems more
active. Both groups have little domain knowledge. That means they are not
neccessarly using the software they create which in turn leads to much less
scratching your own itch and less devotion to packaging.
Debian seems to be most widely know distribution among scientists which is
shown by the number of already packaged scientific/medical software.
> > build_gtm.sh finds out
> > what type of system it is on and builds a deb or rpm accordingly. That
> > way if the whole thing is pulled you just run the script on the type
> > of system it is on and it works.
> But this is not intended. If we provide official Debian packages you
> just know on what system you are.
If you use the corresponding tools you don't need your script anymore. Just
build proper packages once and let the distributions handle updates. Tell you
what. GNUmed has similar scripts as well. Users will use them to screw you in
the worst way. You will never know exactly what the user's environment is when
they report a bug. I would always go for proper packages.
Different from scientific software where the users (scientist) often have a
lot of computer skills including programming and packaging the medical domain
(your audience) mostly lacks those skills. So your want your software to be as
easily available and installable as possible unless you want to earn a lot on