> > 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. 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.
