Proposal for scope of core distro

[Neil Jerram <neil@ossau.uklinux.net>]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> Two parties I'd like to keep in mind when making these decisions:

    Rob>   - the packagers - we should consider what happens if I want to
    Rob>     package guile for debian and we've stuck guile-gtk, qt, kde,
    Rob>     gnome, etc. all in the main tree.  If I build and install with
    Rob>     everything, I can assure you there will be a *lot* of users who
    Rob>     will (legitimately) complain that I'm forcing them to install, say
    Rob>     X, gtk, qt, and gnome on their *non-X* system.  There are a
    Rob>     variety of ways we could handle this, but I think it's important
    Rob>     to keep in mind.

    Rob>   - the special cases -- we should consider what effect any
    Rob>     arrangement we discuss might have on the difficulty of using guile
    Rob>     in small environments.  i.e. the user (or distribution) who wants
    Rob>     to put guile on a firewall, ipaq, or mini-board.  If we only
    Rob>     support a make install of 20MB+, then we're not considering this
    Rob>     case, and IMO it's not very workable to just say "these people
    Rob>     need to pick out the bits they need themselves" -- if we don't
    Rob>     have some policies wrt to our "core", then we'll eventually end up
    Rob>     with all kinds of cross-dependencies between different modules.

These cases are very helpful.  Based on these, and on the feedback
from everyone else on this subject, I'd like to propose the following
plan for the scope of guile-core and other Guile add-on distributions.

- In general, define Guile distributions by their dependencies.

  This is a nice way of looking at things: guile-core becomes the
  collection of all Guile code that depends only on Guile itself,
  guile-gtk the collection that depends logically on Guile+Gtk, and so
  on.

  - In particular, as regards guile-core, we would not allow adding
    anything that introduces any new external dependencies, but we
    would accept pretty much anything that is reasonably stable,
    well-written and of general interest, so long as it doesn't
    introduce any new dependencies.  This includes most new pure
    Scheme code.
  
    (We may need some kind of staging post or review process here;
    cf. the Emacs Lisp archive.)
  
  - guile-gtk, for example, should remain a separate distribution, as
    the rule above prohibits us from merging it into guile-core.  But
    guile-gtk in turn could grow by accepting any new contributions
    whose dependencies were only Guile and Gtk.

- Within a distribution, and in particular within guile-core, we
  should aim to provide full configuration-time control over which
  parts of the distribution are built and installed, with two
  important special cases being "minimal" and "everything".

  In guile-core, we already have a lot of this - try typing
  `./configure --help' to see the control available.  We just need to

  - extend it to cover Scheme module selection (including, in some
    cases, the C libraries that they incorporate)

  - add in implicit dependencies so that we always create a consistent
    build

  - eventually, factor out more of libguile into selectable options,
    so that the "minimal" option can be more so

  - document everything clearly.

  It would be a good idea to track the size of a "minimal" install in
  automated builds, so that if we did introduce a dependency that
  increased the size, we'd notice.

    Rob>     As an example of a policy question -- if we added a
    Rob>     perlre module, would it be OK for the core code to use
    Rob>     it?  How about srfi-1?, etc.

The decision would lie in the details.  According to the above
guidelines, though,

- it _would_ be OK to bundle the perlre module in guile-core, assuming
  that perlre doesn't depend on Perl or anything other new
  dependencies

- the sense of using perlre in, say, srfi-1 could be informed by
  looking at the effect on the minimal install size.

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel