On Fri, 9 Jan 2009 16:24:46 +0100, Michael Hanke wrote: > On Fri, Jan 09, 2009 at 03:37:42PM +0100, David Paleino wrote: > > libodin1, libodin-dev, libodin1-dbg, odin, odin-doc > > > > Obviously, after receiving a reply from upstream. ;) > > Sure. Do as you like, I asked for comments, I'm not doing as I like... > but ask yourself: > > * What other application would these libraries use? > > I really think that these are intended for development _inside_ ODIN > and the result is a simulation _inside_ ODIN and not a standalone tool > linked against some lib that could be packaged on its own. I simply > see no advantage of packaging them as shared libs -- believe me, > shared library packaging is nothing you should start without need. And what if $random_developer wants to #include <odin/foo.h> in his app? Must he be forced to install the whole odin thing? He just installs the lib* packages -- even if those are meant as private libraries. > * Is there any 'plan' how to develop SO versions with upstream? The > upstream build systems does not set any -- I assume on purpose. It does instead, probably not in a good way but it does: $ find . -name Makefile.am | xargs grep -inR "\-version\-info" ./odinseq/Makefile.am:6:libodinseq_la_LDFLAGS = -no-undefined -version-info $(lib_version) -release $(VERSION) ./odinpara/Makefile.am:6:libodinpara_la_LDFLAGS = -no-undefined -version-info $(lib_version) -release $(VERSION) ./odinqt/Makefile.am:2:libodinqt_la_LDFLAGS = -no-undefined -version-info $(lib_version) -release $(VERSION) $(GUILIBS) ./tjutils/Makefile.am:6:libtjutils_la_LDFLAGS = -no-undefined -version-info $(lib_version) -release $(VERSION) $(BASELIBS) ./odindata/Makefile.am:1:libodindata_la_LDFLAGS = -no-undefined -version-info $(lib_version) -release $(VERSION) $(DATALIBS) $ That -version-info is what makes the SONAME version: $ objdump -x libodindata.so | grep SONAME SONAME libodindata-1.7.0.so.1 $ Probably upstream should be educated on a better usage of this, but they *do* have a SONAME. > Moreover, the cpp are the actual templates that are used to develop own > sequences -- IMHO this is more than plain documentation. Just take a > look at the actual user interface. Yes, I already started the GUI before sending my first mail. And, IMHO, they're still documentative: you're "allowed" to write a sequence from scratch, aren't you? (Ok, probably you wouldn't do that, but still can) Those are, as Andreas pointed, "example sequences" -- they are best fit in /usr/share/doc/<something>/examples/ IMHO. > On Fri, Jan 09, 2009 at 03:37:42PM +0100, David Paleino wrote: > > > Without looking again, I see nothing that would demand even two binary > > > packages -- just 'odin' itself. > > > > NAK again. It's just crazy, in terms of package management, having the > > shared libraries and the binaries all in one package :) > > What is it exactly that makes it crazy? Read above: "if $random_developer wants to [..]" (/me thinks you're getting kinda upset for nothing) 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