Re: RFC: packaging layout for Odin
On Fri, Jan 09, 2009 at 04:43:08PM +0100, David Paleino wrote:
> On Fri, 9 Jan 2009 16:24:46 +0100, Michael Hanke wrote:
> > * 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.
Sure. The other half of the topic is: Someone has to check each upstream
release whether upstream was correct in bumping or not bumping SO
version, negotiating with upstream to correct (if necessary), changing
package names accordingly, forcing the package through NEW, ...
Significant increase in workload for a number of people due to 'what if
a random...'
> > * 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.
Ah, I missed that -- good to know.
> > 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.
As I said -- that is my oppinion, but since you package -- you decide.
> > 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 [..]"
Still don't aggree.
> (/me thinks you're getting kinda upset for nothing)
Not at all -- just sharing my thoughts. I can be quiet if you like ;-)
It is just that ODIN is not a random application like e.g. an editor and
it is probably worth discussing things before the become concrete, right?
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
Reply to: