[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal for scope of core distro
From: |
Neil Jerram |
Subject: |
Proposal for scope of core distro |
Date: |
13 Oct 2002 16:09:57 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Rob" == Rob Browning <address@hidden> 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
- Adding stuff to the core distro (was Re: Infix syntax), (continued)
- Adding stuff to the core distro (was Re: Infix syntax), Neil Jerram, 2002/10/08
- Adding stuff to the core distro (was Re: Infix syntax), Han-Wen Nienhuys, 2002/10/08
- Re: Adding stuff to the core distro (was Re: Infix syntax), Rob Browning, 2002/10/08
- Re: Adding stuff to the core distro (was Re: Infix syntax), Neil Jerram, 2002/10/09
- Re: Adding stuff to the core distro (was Re: Infix syntax), Rob Browning, 2002/10/09
- Re: Adding stuff to the core distro (was Re: Infix syntax), Daniel Skarda, 2002/10/10
- Re: Adding stuff to the core distro (was Re: Infix syntax), Daniel Skarda, 2002/10/10
- Re: Adding stuff to the core distro (was Re: Infix syntax), Rob Browning, 2002/10/10
- Re: Adding stuff to the core distro (was Re: Infix syntax), Clinton Ebadi, 2002/10/10
- Re: Adding stuff to the core distro (was Re: Infix syntax), Lynn Winebarger, 2002/10/10
- Proposal for scope of core distro,
Neil Jerram <=
- Re: Adding stuff to the core distro (was Re: Infix syntax), Daniel Skarda, 2002/10/18
- Re: Adding stuff to the core distro (was Re: Infix syntax), Lynn Winebarger, 2002/10/19
- Re: Adding stuff to the core distro (was Re: Infix syntax), Daniel Skarda, 2002/10/20
- Re: Adding stuff to the core distro (was Re: Infix syntax), Bill Gribble, 2002/10/10
- Re: Adding stuff to the core distro (was Re: Infix syntax), Daniel Skarda, 2002/10/19
- Re: Adding stuff to the core distro (was Re: Infix syntax), Neil Jerram, 2002/10/13
- Re: Adding stuff to the core distro (was Re: Infix syntax), Daniel Skarda, 2002/10/18
- Re: Adding stuff to the core distro (was Re: Infix syntax), Neil Jerram, 2002/10/19
- Re: Adding stuff to the core distro (was Re: Infix syntax), Daniel Skarda, 2002/10/10
- Re: Adding stuff to the core distro (was Re: Infix syntax), Neil Jerram, 2002/10/13