Re: RFC: How to organize guile-gnome

[Andreas Rottmann]

Greg Troxel <address@hidden> writes:

> 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).
>
I don't know how NetBSD pkgsrc works, but in Debian you can have one
source package creating multiple binary packages, which then show the
above dependencies. Build-dependencies are only an issue for
developers, who normally don't care about a few -dev packages more or
less.

> 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.
>
Hmm, Debian solves all this by having file (pattern) lists for each
binary package. I'm not at all against a fine-grained release tarball
set.

Regards, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Say NO to Software Patents! -- http://petition.eurolinux.org/