Re: RFC: How to organize guile-gnome

[Andreas Rottmann]

Greg Troxel <address@hidden> writes:

> I'm a bit behind in playing with this, so apologies if I'm off.  I see
> several separate pieces:
>
>   glib2 core support
>   ORBit2/corba support
>   gnome-core stuff
>   various gnome applications
>
> I think it would be optimal if one could build guile-gnome with any of
> the first three levels of support.
>
> The last part IMHO doesn't really belong; I'd like to see guile-gnome
> be able to provide glue (installed) that can then be used for other
> wrappings.
>
Sure, applications have no place in guile-gnome, as its about
bindings.

> I think it would be really unfortunate if one needed to install
> gstreamer to build guile-gnome.
>
All bit the first (glib/gobject) will be optional in any build (it is
already).

> I think it would be best to have a guile-gnome-foo package for each
> foo, but with that depending on the base guile-gnome already
> installed.  I say this from the perspective of using guile and gnome
> on NetBSD with pkgsrc, thinking about how this code will get packaged
> (which is a bit separate from how it is released).
>
>From a the "GNOME binding release set" POV, we should have a package
(or set of packages) that covers the modules in the GNOME developer
platform. This might mean either a package (read: tarball) called
guile-gnome, which has all that stuff, or we might do tarballs like
this:

guile-gobject -- absolute core
guile-gtk     -- GTK+ bindings
guile-glade   -- Glade bindings
...

It just depends on how much granularity you want. Bindings other than
for the GNOME developer platform must be in one or more packages
disjoint with the package (set) for the platform.

> Honestly, guile is not mainstream yet, so it is important IMHO to
> make things easy for packagers, since that leads to guile being used
> in things like gnumeric where it is optional.
>
Sure.

> How you propose things in CVS sounds ok; the main thing to me is to
> have the separate release tarballs.  Having the all-in-one is not
> important in my view, and may tend to be harmful, since a packager
> might take that and not do the others, leading to dependency pain.
>
My mail was mainly how to organize stuff from a source configuration
managment POV, not so much how we then partition our modules into
release tarballs.

> ORBit2 is small enough and core enough that if the really base package
> does glib2 and corba that's probably fine.
>
I tend to agree, especially we will make all but the absolute core
libraries (i.e. Glib/GObject) a optional build-dependency.

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

Packages should build-depend on what they should build-depend.