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

[Shaya Potter <spotter@kby.netmedia.net.il>]

At 05:14 PM 12/9/97 +0100, Christian Schwarz wrote:
>
>While the large number of packages makes Debian the largest distribution
>it also introduces a few disadvantages:
>
>- 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.

I would also add, that the overall cohesivness of the distribution
deteriorates because of all the packages.

>
>- 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.

Some people have argued that it's Ok to just write documentation, like "This
is how this is done in smail ....  For sendmail, we leave it up as a project
for the user".  IMHO, that's beyond bad, it makes the documentation a joke.
I don't think we should remove packages that don't have good documentation,
but a criteria for inclusion in the "core" debian distribution, could be
that the packages is documented well, and can be integrated into Debian's
documentation. 

>
>- 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.

This goes along with what I said b/4 of giving the distribution a cohesive
feel. Any sort of cohesive feel is diminshed if each application deals with
the keyboard differently.

>
>- 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.)

This is not a serious issue, in my book, because hopefully the switch b/w
FSSTND and the FHS shouldn't be too hard (Q. does anyone know what are the
serious changes we will have to make, if any?)  and the libc6->libc7
migration would be from one virgin GNU-libc to another one (hopefully), so
any bugs that come up in recompiling are probably bugs in the libc itself
and will be fixed by other people besides us.  I may be wrong, or this may
be wishfull thinking, I'm willing to be corrected.

>
>- With fewer packages, it would probably be possible to have a few people
>"maintaining" the stable releases. I'm sure, this would get us a lot new 
>users.

That's if you think that "stable" is being maintained right now.  :).  What
would probably be helpfull (as most maintainers always run unstable) is to
have a fast machine likes master, (stable.debian.org?) that all the
developers can have accounts on, and use that to compile for stable. yes,
people have offered machines to be used in this way, but the problem is that
those are really private machines and 1) we have to ask for use of them and
2) Some people might not want to bother the people that have offered the
machines.  It would probably be best if we have a "stable" machine that
comes totally under Debian's auspices.  

>
>- More companies might offer commercial support for Debian systems if the
>distribution would be a bit more "compact". (Currently, I think it's hard
>to offer support for 1600 pieces of software.)
>

This I definitly agree with, because as I mentioned b/4, when I was talking
with the author of linuxconf, he told me he aims linuxconf at Red Hat and
slackware (don't know about slackware anymore) because with those systems
you know what programs are going to be on the system, sendmail as the MTA,
apache as the web server....  with debian you don't know what the use
installed or their is too much choice that it's impossible to support all
the pieces.  Companies, might be willing to support debian if we can cut it
down to the "Core" debian, and then support the core, and we could still go
on including the rest of the packages, in the same manner that we do know.
i.e. with not much "official" support.

>
>Now back to our current situation:
>
>We already have divided our packages into three "areas", namely main,
>non-free, and contrib. When we speak of the "Debian GNU/Linux
>distribution", we usually refer to "main". That's because we want to build
>an operating system which consists only of free software components, as
>defined in the social contract. 
>
>Though, the packages in "non-free" and "contrib" are still actively
>maintained and have to follow our policy (best as possible). Furthermore,
>we use the same resources (bug tracking system, mailing lists, etc.) for
>these packages.
>
>Now to my suggestion: (Please note, that this suggestion is still in
>_draft_ state :)
>
>We could split "main" into smaller parts, namely a "base" distribution
>and a few "add-ons". The "base" part (not to be confused with the current
>"base" section--I'm still looking for a better name here) will form the 
>new "Debian GNU/Linux" distribution (or operating system).

I like this idea.

>
>The "add-ons" parts will also be fully "DFSG-free", will be maintained by
>Debian developers, and will also have to follow our policy. I'm thinking
>of a "Documentation add-on" which includes a lot of non-technical e-texts
>(the bible, all texts from the Gutenberg project, etc.), a "Perl add-on"
>which contains the whole CPAN packaged up in deb packages, a "TeX add-on"
>which is nothing else but CTAN packaged up, a "Multimedia add-on", etc. 

However, their should still be certain Perl and TeX packages in the "core"
part of the distribution.  i.e. normall TeX stuff, not the esoteric packages
that most people who use TeX or perl normally use.

>
>For practical reasons, the add-ons should probably not exceed a CD-ROM,
>including source code.
>
>Then we might choose some nice names for our distribution parts, for
>example,
>
>     Debian GNU/Linux Base Distribution
>     Debian GNU/Linux Multimedia Extension
>     Debian GNU/Linux Perl Extension
>     Debian GNU/Linux E-Texts Extension
>     ...
>
>How does this sound? (Professional, IMHO :-)

Sounds good to me.

>
>This setup should solve most of the problems I explained above, while
>keeping the flexibility and the variety of packages we currently have. So,
>a Linux newbie could start installing the base distribution. (Ideally, the
>installation should not require knowledge of any packaging details as it
>does now. It should suffice to say "I want X, development stuff, a web
>server, no TeX, ..." for newbies.--We might implement this on top of the
>current installation procedure so that the "freaks" don't loose the
>flexibility we currently have.)

What we may be also able to do, to increase the market that the "extenstion"
CDs will be aimed at, is to include alien as an .rpm and the proper "patch"
files for these CDs, so that people who use RedHat systems can take
advantage of them too.  just a thought.

Well, hopefully I got my ideas across well, as I don't have much time to
type this up (as I have a very limited amount of e-mail time a day) and have
had to type this up b/w sittings, so don't yell to much if it's totally off
the wall.

Thanks,

Shaya


--
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 .