Re: Packaging EMBASSY.
Il giorno Wed, 26 Sep 2007 11:19:35 +0900
Charles Plessy <charles-debian-nospam@plessy.org> ha scritto:
> Dear all,
Hi,
> I have progressed faster than expected on cleaning EMBOSS bugs, and this
> lead me to start to package EMBASSY, which is a set of additional
> programs for EMBOSS that are either work in progress of wrappers for
> external software.
If you need any help, I'm available :)
> EMBASSY programs have to be built against EMBOSS libraries. Currently,
> these are Ajax, Nucleus, and Eplplot.
As Andreas already noted, Ajax is a very common name nowadays. There might be
some name conflicts in the near future.
We could:
1) suggest upstream to change name;
2) change the debian package name, patching the software where needed, but this
is a really big effort.
> Since the developpment packages I
> prepared (libajax5-dev, 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. Would it be better to leave the header files
> in /usr/include? Is there another way to tell to the compiler that it
> has to look in /usr/include/ajax and /usr/include/nucleus?
I believe it's better putting them in something like /usr/include/embassy, if
they're package specific. Otherwise, the name change for libajax is needed, and
using subdirectories is the best choice IMHO.
> As EMBASSY packages are ./configure && make && make install packages, I
> decided that factorizing as much code as possible was important, and
> used CDBS for their building. Please inform me if you have strong
> opinions about this, or if you know smarter ways of factorizing code
> with SVN. I am open to other solutions.
I don't really like CDBS, it's like a black box to me. I mean, you just include
makefiles, and don't know what they're doing behind the curtains. I prefer
debhelper makefiles (the "classic" debian/rules with dh_* calls), which let you
define each action of the build process.
> 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...
We should try, but after the first release we should contact upstream anyway,
there's no point in patching every single EMBASSY release to use plplot instead
of eplplot, if upstream doesn't wish so.
> 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
> first.
I believe that a release could be a good thing. Consider that, instead of just
us Debian-Med developers, we'll have a major public to test EMBOSS with. Most
than probably, there will be bugs filed which we didn't / don't notice, and
that's a good way to improve software. Well, at least IMO :)
>
> ...
>
> Have a nice day,
You too,
David
--
. ''`. Debian maintainer | http://snipurl.com/gofoxygo/
: :' : Linuxer #334216 | http://www.hanskalabs.net/
`. `'` GPG: 1392B174 | http://www.debianizzati.org/
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Reply to: