Re: RFC: How to organize guile-gnome

[Greg Troxel]

Sorry, I haven't been clear enough (and I hope I'm not annoying
anyone).

I agree that from the perspective of a person on a machine who wants
to build any of this that the normal configure-test setup of checking
for dependencies and only building/installing the corresponding pieces
works fine.

I am thinking of NetBSD pkgsrc (debian should have substantially the
same issues).  As a packager I want to build separate packages for the
separate pieces, so that there can be a directory with binary
packages, and a user can install what they want.  If someone builds a
program foo that depends on only the guile-gobject-glib part, then
installing foo will install the guile-gobject-glib package.  Then if
one installs bar which depends on gtk bindings, that will install
guile-gobject-gtk (which depends on guile-gobject-glib as well as gtk
itself).

One approach would be to make a just glib and a glib+gtk package, have
them conflict, and have glib things depend on either.  This means that
if you already have one installed you have to replace it, and that's
ugly.  It's much nicer to just be able to install the gtk part when
you need it.

Another appoach would be to only provide the full-blown package, and
make it depend on everyhing it takes to do that.  With packaging, I
find the mentality is not 'configure what's there' but 'depend on what
you want to be found by configure, and --disable the rest' so you get
consistent package behavior.

What is needed to do this cleanly (in the style of pkgsrc :-) is to be
able to not only --disable things but also to only install e.g. the
gtk piece but not the glib piece (with the requirement that the glib
piece is already there).

Some programs (amanda, coda) have targets to 'install-client' and
'install-server' that install parts.

NetBSD does this with the gnome-core package (removing panel, applets,
smproxy, and gsm).  gnome-applets is available separately, so that pkg
is easy, but gnome-core has this to avoid installing some things:

pre-install:
.for dir in gsm smproxy panel applets
     ${ECHO} install: >${WRKSRC}/${dir}/Makefile
.endfor


  Hmm, I think the current model is easy to grasp: configure checks all
  *external* dependencies, the bindings for those satisfied are built
  (and installed on 'make install').

Easy to grasp, yes, but it doesn't provide a way to install a piece
without installing all the preceding pieces.  With separate tarballs,
one can simply package each one.  Whether they are separate doesn't
matter much; the key feature from my POV is being able to install only
some (later) parts without installing the more basic parts.  I think
the configure model only supports going up the tree so far, not only
installing the leaves.