Re: Clarification about the idea to "split the distribution"

[Rob Browning <rlb@cs.utexas.edu>]

Christian Schwarz <schwarz@monet.m.isar.de> writes:

> - A lot of users are overwhelmed by the large number of packages when they
> are installing Debian for the first time. (The new "deity" might improve
> this situation--we'll see.) Furthermore, digging through 1600 packages
> takes some time and "having time" is our biggest problem, as we all know.

To my mind this is almost exclusively a UI and marketing decision.
The UI can make however many packages we have managable, and deciding
how to break the distribution up into CDs is a marketing decision
(important, but still a marketing decision).

> - It's hard to write documentation for the Debian system as a whole since
> you have too many special packages. E.g., if you write a section about how
> "vi" works, you'd have to explain elvis, vim, nvi, etc. Same applies to
> mailer daemons, web servers, etc.

It may be hard, but I think it's the right thing to do.  It think it
is a great strength that Debian has as a goal "doing the right thing"
with complex issues like supporting a simultaneous install of emacs19,
emacs20, and xemacs, or correctly handling whichever of the major MDAs
the user prefers.

People can always write documentation for a specific package if they
want "here's how to do foo with the default mailer, smail, doing this
with sendmail should be easy (if you know sendmail :>), and is
supported, but left as an exercise for the reader".

> - Projects like the "keyboard configuration project" are really hard to do
> because they affect a large number of packages. Such efforts will get even
> worse if the package count continuous to increase.

Not necessarily.  Coming to the conclusion is the hard part.  Once
policy is made, then the task of implementing it can be substantially
distributed as long as we have maintainers for the affected packages.

> - The more packages we have, the more time we'll need to implement major
> changes. For example, we'll have to switch from FSSTND to FHS for Debian
> 2.1 and there might be a libc6->libc7 migration some time. (A lot of
> people think that we should release "hamm" ASAP since Red Hat 5.0 has
> already been released a few weeks ago. Since we have more packages than
> what they have, it's obvious that we need more time.)

Again I think this is more substantially affected by the
maintainer/package ratio than the absolute number of packages.  Each
maintainer has to read the FHS and implement the policy for their
packages.

The biggest impact, and the most legitimate gripe I can see, is the
impact on the *testing team*.  Unless we can easily increase the
number of testers (which is no trivial task), then absolute numbers of
packages becomes a more substantial issue.

With respect to the rest of the proposal.  I agree that as the number
of packages rises, we are going to have to figure out how to
reorganize the package repository to make it easier to break the
distribution up into CD's, and perhaps even to make it possible to
distribute things across multiple ftp sites.

However, I don't think this calls for a 1st class/2nd class package
distinction to any extent greater than that implied by the current
Priority field.  It is true that we'll probably need to pay more
attention to the core packages before releases, but I don't think we
could seriously consider a new stable release if, say, the TeX
packages aren't all up to standards, even if the TeX stuff is off in
it's own "add-on".  So in the end, for most packages, we'll still be
doing the same thing we do now.

To summarize: I think that making it easier to produce a main CD and
add-on CDs (TeX, CPAN, etc) is probably a good thing, and will become
more important as the package count grows.  What this means wrt to ftp
site organization is less clear to me.  However, I don't think that
making a stronger distinction between "core" packages and other
packages than we already have will really help anything.  We'll still
have to deal with the "other" packages before a release -- a broken
CPAN or TeX add-on could easily be *much* worse for many users than a
broken setserial.

</ramble>

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .