[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#409849: First rough draft of an afni Debian package



On Tue, Oct 20, 2009 at 06:01:12PM -0400, Judd Storrs wrote:
> >
> >  The place is fine, but how did you determine the subset of headers that
> > should go into it. If we can automize that, it might scale a bit better
> > with the future AFNI development.
> >
> > However, the more serious problem is that having a -dev package also
> > implies that the libs can be used elsewhere -- which is actually not
> > the case. Without a proper versioning scheme and sane interface policies
> > we cannot expose the shared libs (that I imagined to be internal
> > convenience libs) like this. What could be done is adding static libs to
> > the -dev package. However, already now it is significant pain to build
> > shared libs alone -- building both is even more tricky using AFNI's
> > cumbersome build system...
> >
> 
> It's based mostly on the LIBHEADERS list in Makefile.INCLUDE. I also
> included afni.h and all its dependencies because afni.h is needed to compile
> plugins for the afni viewer. I'm working on a plugin and I noticed I
> couldn't compile, but you're right. I'm not sure which of the headers are
> needed for full functionality of the libraries. Another approach would be to
> install all the headers that don't originate from other packages.
> 
> I'm not sure I would bother with static libraries.  An alternative would be
> to get rid of afni-dev altogether and include the headers in
> /usr/lib/afni/include as part of afni-common or something. LIBHEADERS are
> distributed in the binary packages from the NIH so debian would just be
> doing what they already do. NIH doesn't include afni.h so that can probably
> be omitted.

Nah, we should do it properly. If people develop plugins (and apparently
they do) we should support that with a proper -dev package. I will take
a look at this issue.

> > AFNI.afnirc and AFNI.sumarc are now simply shipped as examples in the
> > afni-common package, but I guess they should become somewhat more
> > functional. My own config scheme in /etc/afni/afni.sh takes care of the
> > most critical settings, but the majority is left untouched. I am not
> > sure about implementing a proper default system-wide config setup --
> > right now this per-user thingie that comes with AFNI feels incomplete
> > and suboptimal. Advice is most welcome, since I am not really a
> > proficient AFNI user.
> >
> 
> I think the way you have done it is best. It is important to avoid burdening
> the NIH developers with problems that originate from the debian packaging. I
> would leave things the way they would be if the user had downloaded the
> binary builds from the NIH directly--i.e. no configuration--let's not
> surprise the NIH. The path setting in /etc/afni/afni.sh is good because it's
> necessary. I'd resist the urge to improve unless there are debian-specific
> advantages/reasons. Otherwise it becomes another layer of confusion when
> newcomers post to the message board. The .config/AFNI stuff--that's OK, but
> AFNI already uses .afnirc etc and I doubt anybody on the message board is
> going to know about .config. My feeling is that users would expect the
> debian package to help install afni and dependencies and help keep it
> up-to-date.

Point taken. However, .config/AFNI/* (shell script) is different from
.afnirc (afni's own format) -- but yes the Debian package's behavior
should be identical to the upstream AFNI distribution. But we might
nevertheless achieve that in a slighlty more elegant way ;-)

Michael

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de



Reply to: