On Fri, 9 Jan 2009 09:32:42 +0100, David Paleino wrote:
> On Thu, 8 Jan 2009 22:39:38 +0100, Michael Hanke wrote:
>
> > [..]
> > On a related issue there is also still unpackaged ODIN [2]. There had
> > been an RFP [3] and some activity by David, but the current status is
> > not clear to me. I had a quick look at it today and it looks like an
> > easy target. It would definitely be worth to packaging it -- anyone
> > working on that one?
>
> Just FYI, I've started working to package ODIN.
Ok, now with some real issues.
ODIN provides a quantity of libraries, development headers, documentation and
binaries, which I'm trying to split in proper Debian packages.
In /usr/lib/ we can find:
$ ls -1 *.so
libodindata.so
libodinpara.so
libodinqt.so
libodinseq.so
libtjutils.so
$
Those libraries carry their own include headers as well:
$ ls -1d ../include/*
../include/odindata
../include/odinpara
../include/odinqt
../include/odinseq
../include/tjutils
$
It seems like I should create these packages:
libodindata1, libodindata-dev, libodindata1-dbg
libodinpara1, libodinpara-dev, libodinpara1-dbg
libodinqt1, libodinqt-dev, libodinqt1-dbg
libodinseq1, libodinseq-dev, libodinseq1-dbg
libtjutils1, libtjutils-dev, libtjutils1-dbg
(only the libraries, they sum up to 15 packages -- and yes, the -dbg ones are
IMHO needed, we don't want our non-developer-users to recompile stuff on their
own, right?)
Then we have:
$ ls ../bin/
gencoil gensample micalc miview odinreco pulsar
genmakefile geoedit miconv odin odintestsuite swab
$
These might go into a single "odin" package, if you agree.
Then there is /usr/share/doc/odin/:
$ tree
.
`-- doc
`-- odin
|-- coils
| |-- Array8Channel.coi
| `-- radialInhomogen.coi
|-- samples
| |-- brain_128x128.smp
| |-- disk_128x128.smp
| |-- frequency_dist.smp
| |-- point_spread_function.smp
| `-- qualityPhantom_128x128.smp
`-- sequences
|-- odinepi.cpp
|-- odinfisp.cpp
|-- odingrech.cpp
|-- odinmdeft.cpp
|-- odinonep.cpp
|-- odinpilot.cpp
|-- odinquant.cpp
|-- odinrare.cpp
|-- odinrefg.cpp
|-- odinspir.cpp
|-- odinswi.cpp
|-- tj_bgmes.cpp
|-- tj_messer.cpp
`-- tj_verve.cpp
$
It's a total of 1,6M, so we can decide to have an extra single "odin-doc"
package (I thought at odin-samples, odin-coils and odin-sequences, but those
are just examples, so IMHO not worth having their own separated packages)
Total: 17 packages from a single source. Now, this isn't really a problem, but
the problem arises whether or not those libraries are intended for "public
use", or they are internal to odin. If they are just internal, I could make a
libodin1 package, adding proper lintian overrides, and put them into a
subdirectory of /usr/lib/ (/u/l/odin/ would be best). Also, it is possible that
they all are internal but libtjutils -- in this case I'd do libodin1 and
libtjutils1.
Obviously, I'm compiling it without libvista support -- but we'd still have a
rather useful package in the repositories, and we can always recompile it and
upload a new revision, when vista will be ready (-- if ever).
Time, CPU cycles and heating permitting, I will try to recompile everything and
make those 17 packages.
Kindly,
David
--
. ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature