suggestion: move all java packages to extras

[Arjan van de Ven]

On Sun, 2005-11-27 at 10:10 -0500, Matthew Miller wrote:
> On Sun, Nov 27, 2005 at 07:37:08AM -0700, Tom Tromey wrote:
> > I don't doubt this.  However implicit in this is some idea of what the
> > target Fedora Core user looks like -- some kind of user profile.  I
> > think the goal of this thread is to make this idea explicit.
> > Are we targeting developers?  Corporate desktop users?  People who
> > travel a lot?  People setting up LAMP servers?  Some combination?
> 
> I'm for going all the way -- it should contain no end-user applications,
> just the framework for making those applications run. C'mon, let's make Core
> be just that.

actually I tend to disagree, not sure how much say I should have in this
though.

I think of it as an union model, where each layer is both self-contained
in terms of package dependencies but also in the requirements it
fulfills in terms of user/market.

eg

layer 0 of the union
"base" - minimum set to get the machine booting and operating

layer 1 of the union
"core" - set of functionality people expect from a consumer oriented
linux distro

layer 2 of the union
"extras" - more "obscure" functionality for example because it's a
relatively small userbase but also because it can be new and emerging
things. In addition this can be alternative implementations to core
functionality. An example of this could be wu-ftpd or xfce or ..

layer 3 of the union
"dedicated repos" - very specialist repositories that each target what
is pretty much a niche market and who's requirements are very different
or unique but isolated. Examples could be a beowulf repo, or a "video
montage" repo. 

again, for me it's essential that each layer of the union is
self-contained in terms of packages (eg no dependencies to higher
layers, lower layers is of course ok) and of functionality (eg if a
layer contains a certain functionality, it should contain in a general
useful matter. this doesn't mean that all optional things should be
there, but enough functionality that most people expect should be
there).

For me the difference between layer 2 and 3 is also a "market segment"
one. Some things will be so specialist that it's better to have a few
experts have their own repo that they maintain as a coherent add-on
function than lumping it all in one big repo.