[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Flavors y metadistros [FWD] Re: Future of Debian !uncertain (from: aj@azure.humbug.org.au)

  Yo cada vez veo más la necesidad de que en Debian se conozca
  Metadistros y se pueda ayudar y colaborar en su desarrollo.

  Y si leéis la plataforma de Martin Michlmayr[1] como candidato a DPL
  habla también de lo mismo.

  [1] http://www.debian.org/vote/2003/platforms/tbm

----- Forwarded message from Anthony Towns <aj@azure.humbug.org.au> -----

From: Anthony Towns <aj@azure.humbug.org.au>
Subject: Re: Future of Debian !uncertain
To: debian-devel@lists.debian.org
Date: Thu, 27 Feb 2003 05:40:17 +1000
Organisation: Lacking
Message-ID: <20030226194017.GB17817@azure.humbug.org.au>
In-Reply-To: <20030226172248.GC31930@dragon.kitenet.net>
X-Mailing-List: <debian-devel@lists.debian.org> archive/latest/137745
Mail-Followup-To: debian-devel@lists.debian.org
User-Agent: Mutt/1.3.28i
X-Spam-Status: No, hits=-3.7 required=6.0

On Wed, Feb 26, 2003 at 12:22:48PM -0500, Joey Hess wrote:
> The reason you can install Mandrake or whatever and get a
> well-configured, working desktop automatically set up for you is that
> Mandrake has decided that they will cater to the set of people who want
> a nice desktop without any work. They will make decisions for them.

> The reason installing a Debian desktop takes a phd is because the
> installer is just as happy to let you go off and build a shell server
> on a m68k. Or a ratpoison "desktop". Or a headless X font server/xdm
> server. Every branch in this path requires a decision from the user, since
> Debian is afraid to make any decisions for them. 

First, a caveat: not making decisions is often good; it's horrible when
software makes the *wrong* decision for you. I'd much rather a system
that does nothing at all, than one where I have to continually fend off
offers of "help", that really aren't. Working out which decisions to make
in which contexts, and working out how to make them is a hard problem [0].

But aside from that, I think there's an interesting point here that
hasn't quite crystallised yet. It's related to the flavours stuff that
Bdale has mentioned a few times that sparked a fair bit of interest at
the Debian miniconf at linux.conf.au this year.

At its simplest, I think, the idea is that we ought to be able to
"extract" a flavour from Debian [1] in some automated way, and that
we should then be able to give this flavour to someone who can then go
about their business without having to remake all the same decisions.

There are obvious things that this would mean. A flavour would have to
be able to include various non-standard packages. It'd have to be able
to stop the user from being prompted for various things. It'd probably
have to be able to tell the installer exactly what to do.

There are more subtle things too, that are harder to get right. It'd
have to allow you to choose other packages without presenting you with
the entirety of Debian, but still cope with dependencies and conflicts
correctly. If you've been given the Internet server flavour of Debian,
you may or may not want to install postfix or sendmail, but you don't
generally want to have to wade through hundreds of games or thousands
of lib* packages. This probably means you want to integrate with dselect
and aptitude, somehow.

You also need to be able to configure packages automatically. And when
you upgrade, you definitely don't want to be confused with messages from
dpkg that claim your automatically configured conffiles were modified.

You also need to make sure you can back out of a flavour if you find
you're no longer using a machine for the same purpose as you were in
the past. Or switch to a different flavour, or run multiple flavours

The canonical example of flavours is a "Debian for HAMs" CD. Others
might be "Debian GNOME", "Debian Desktop", "Debian for Small Business",
"Debian Server", "University of Debian CS Dept Workstation".

There are other sorts of decisions we can make as a class for our users.
One is for i18n. If you're from France, then it's probably obvious what
your timezone is, what your preferred language is, what character set
and keyboard you're using, and that you'd like the -fr version of any
documentation packages installed. If you're a C developer, you probably
want the lib*-dev versions of any lib* packages installed. For perl,
lib*-perl, for python, python-*. Another example is for common sorts of
computers: if you've got an Apple iBook, there are only a few ways you
want to configure X, you want USB and IEEE1394 configured, you want a few
extra packages installed to make some of the special keys work and get
power management working, you probably want to be prompted on what keys
to use for middle and right mouse buttons. These might or might not be
"flavours". They might or might not be managed using similar technology
to flavours.

In some cases, we already do this sort of thing. We usually make the
decision "If you install this package, you want it operational and
available" for our users, eg. We have various tools to automatically
write various config files for us. We have tasks to help us get some of
the package sets we want.

The issue, I guess is something like:

	* Centralising the decision making for various issues, so you
	  can make a single obvious decision where you currently have
	  to make a multitude of subtle ones

	* Making it possible to burn particular decisions onto a CD to
	  give to someone, without having to make that decision for
	  everyone who uses Debian

I don't know how we'll achieve that.


[0] And it's not even one that can be solved at any one particular level.
    Sometimes, you're going to be able to make a global decision "I
    want this computer setup in the normal way" -- whether you're an
    ignorant home user, or a corporate admin setting up a standard
    desktop, other times you'll want to be able to select packages
    individually. Sometimes you'll be happy to do some standard
    configuration with some basic admin tools (debconf, ifup, groupadd),
    other times you'll want to carefully script exactly what you want,
    with absolutely basic tools.

[1] Maybe "shining Debian through a prism to extract the different
    shades" is a prettier analogy

Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Dear Anthony Towns: [...] Congratulations -- 
        you are now certified as a Red Hat Certified Engineer!''

----- End forwarded message -----

  Jose Carlos Garcia Sogo

Attachment: pgpN9GfHkXBwl.pgp
Description: PGP signature

Reply to: