Re: RFC: packaging layout for Odin (was: Re: Status of ODIN, VISTA and friends)
Hi,
see below....
On Fri, Jan 09, 2009 at 03:07:27PM +0100, David Paleino wrote:
> 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.
Please _don't_.
All those libs are similar to plugins and there to be linked against the
compiled sequences created with odin -- that happens when users use
ODIN. I cannot say for sure, but I'd suspect that they have no other
use, hence should go into the 'odin' package itself.
Additionally, I'd say that everything you have listed under doc/ is a
little more than that. I consider it more of a library of snippets to
play with when developing sequences. I'd put it under /usr/share/odin in
the sense of data files.
Without looking again, I see nothing that would demand even two binary packages
-- just 'odin' itself.
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
Reply to: