Re: Packaging EMBASSY.
On Wed, 26 Sep 2007, Charles Plessy wrote:
EMBASSY programs have to be built against EMBOSS libraries. Currently,
these are Ajax, Nucleus, and Eplplot. Since the developpment packages I
If I where you I would advise upstream that Ajax is not a clever choice of
name since nice and shiny new web 2.0 world and Ajax based browser applications.
I'd consider a name change in the future.
libnucleus5-dev) provide a lot of header files,
I moved them in /usr/include/ajax and /usr/include/nucleus respectively.
However, the EMBASSY programs expect the files in /usr/include.
Therfore, I patched their makefiles. I am not completely sure if what I
did was the right things.
Well, the right thing (TM) is a things this works, isn't it?
Would it be better to leave the header files in /usr/include?
If you ask me for esthetical reasons large sets of include files are
better in subdirectories of /usr/include and if this is good for Debian
it is also good for upstream. So I would probably (once I'm writing
an e-mail to upstream) give this as a second hint - also considering to
reduce a further name clash problem, because there might be chances
for equally named header files that are better residing in subdirectories
to avoid any potential conflict.
Is there another way to tell to the compiler that it
has to look in /usr/include/ajax and /usr/include/nucleus?
Not that I know of. If the programm compiled fine, you did it just right.
Last but not least, you may have noticed that I mentionned the Eplplot
library, but did give it a proper package. The reason is that it was a
quite divergent fork of the plplot library in the past, but that it
seems to have been updated in EMBOSS 5.0.0. Therfore, building EMBOSS
against Debian's libplplot could make sense, but on the other hand this
work may be a significant undertaking. Until we ask upstream or try by
ourselves, we will not know...
Talking to upstream is always a good idea - this would be a third point
to mention. Just try to convince them that they are able to save time
if they try to use original plplot library - perhaps sending some needed
patches to plplot authors if they are missing some features.
For the moment, all the -dev and non -dev
parts of eplplot are in the emboss-lib package, in which they were from
the beginning of EMBOSS packaging. I am still wondering if we should try
to release EMBOSS or EMBASSY soon, or if we should try to work this out
Well, to have a package that works in unstable is a reasonable short term
goal. Making it better regarding quality is a long term goal that should
be tackled afterwards, IMHO.
Two preliminary EMBASSY packages are already in our SVN, alongside with
a script which automatically builds the manpages (in /tools).