gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Re: Issues with 0.5 detected when trying to package


From: Andreas Tille
Subject: [Gnumed-devel] Re: Issues with 0.5 detected when trying to package
Date: Sun, 16 Aug 2009 16:59:42 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Aug 15, 2009 at 07:54:33PM +0200, Karsten Hilbert wrote:
> > Shouldn't this be v11?
> 
> It should but the file is only an example. It is usually helpful
> to be able to think.

Well, I'd call this a weak excuse.  The examples should work out of
the box with recent code, right?

> >    1. INSTALL_BASE="/usr/bin" - no, I will *not* provide a script
> >       which moves any file not under control of the package manager
> >       to /usr/bin.  I can't avoid that admins do such things, but I
> >       will not tell them to do so.
> >       --> I would generally advise to use
> >         INSTALL_BASE="/usr/local/bin"
> 
> That's true. Will fix that.

OK.
 
> >    2. The script would also require Java (well, not your installer
> >       script, but the jar you are installing.  So what is the sense
> >       to install a piece of software without ensuring that it will
> >       work.  This could be done with an extra Recommends / Suggests
> >       openjdk-6-jre (if the jar works with this).  But I would really
> >       hesitate to bloat gnumed-client dependencies to much.
> 
> Only gnumed-client-de. Make it Suggests.

I can do this.
 
> >    3. Guessing from the name the script is intended to be called
> >       only once (to install a piece of software.  IMHO the solution
> >       of choice (even if the two items above would not be valid)
> >       would be to move this to /usr/share/doc/examples or something
> >       like this.
> 
> Well, that's up to you as packager. But then you'll break one
> functionality of GNUmed (well, not sure, can't check right now,
> it might work as well since it may call it with the PATH, not directly).

So the downloaded JAR file is actually used from the code?  Than this
makes sense.  But I'd like to have some more information about this.  Is
there something in the GNUmed docs?  What is the license of this JAR.
Could we probably ship it as real Debian package?     
 
> >       Executables in /usr/bin need a valid man page
> >       as documentation - well I really think this script deserves
> >       documentation anyway - and you obviosely have refused to
> >       write such anyway.
> 
> No one asked so I can't have refused. Anyway, better move to
> /usr/local/bin/ then   :-)

Well, lintian will definitely ask once I would move the downloader
to /usr/bin.  And if you convince me to really move the downloader
to gnumed-client-de I would really need a manpage to keep lintian
quiet.  And it is not only to make lintian happy - any executable
should really have a documentation.  An alternative might be to
move it to /usr/share/gnumed where it is hidden from users eyes
who might call it by chance but could be called from gnumed code.
 
> >   The other two downloaders: Please explain the sense of moving
> >   data to /tmp rather than to /var/lib/gnumed/(tmp).  The
> >   directory /tmp is removed after each boot process.  So what is
> >   the sense of these data and how are the scripts used?
> 
> They are called from within GNUmed to download updates of the LOINC
> and ATC reference data sets. After they are downloaded they get
> imported into the database. No problem if they are deleted at the
> next cleaning of /tmp. In fact, we *want* that :-)

So what about also moving these to /usr/share/gnumed.  They are
obviosely not useful in the PATH of a user but make perfectly sense
in /usr/share/gnumed.  Would you consider this for 0.5.1 please?
 
Kind regards

     Andreas. 

-- 
http://fam-tille.de
Klarmachen zum Ă„ndern!




reply via email to

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