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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
