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

Re: Future of Debian !uncertain



#include <hallo.h>
* Anthony Towns [Thu, Feb 27 2003, 03:43:00PM]:
> On Wed, Feb 26, 2003 at 07:32:09PM -0600, Graham Wilson wrote:
> > this makes me think, couldnt a flavor just be some set of debconf
> > defaults? that way it could be burned onto a cd, and a package doesnt
> > need anything extra to support the flavor idea.
> 
> Reread my original message; it *can't* just be this. Flavours need to be
> more powerful -- they at least need to interract with dselect/aptitude
> to allow you to only list some subset of packages, and to change the
> effective priorities of many of the ones that are shown.

So let's summarize things that need to be done to implement at least
parts of what has been mentioned in this discussion. There are some
feasible which may improve the smoothness of the installation, maybe not
for idiots but for people that annoyed by doing same and same things
that are typical for a certain environment and could be done better.
First, technical extensions in the dpkg format (description below):

- Debconf-Priority: int
  Depends-Cond: foo -> bar, x -> y, v -> (w | z (>= 1.2.3)
  Rating: desktop ([int:0..100]), home-ws ([int:0..100]), [list of keywords]

 - A major rule for debconf users: there are no questions without a
   reasonable default when the user has choosen his system flavor.

 - Central config file for flavors, outside of debconf&co., say
   /etc/system-profiles
   containing just the keyword that the user has choosed during the
   initial installation (in D-I)

 - When DEBIAN_PRIORITY is set to high and flavor keywords exist, the
   config and postinst scripts should choose sane defaults without
   bothering the user, based on that keywords
 
 - Packages with higher Debconf-Priority: would be processed before
   others. This would allow packages like "demudi-setup" to ask the user
   the few really needed questions and preset the debconf settings for
   other packages (or packages like "home-box-setup" to ask what the
   ISPs mail server is and set all things as needed).

 - conditional dependencies would help to hold the user masses away from
   typical mistakes, like forgetting to install the xfonts-base package
   (xfree86-common could just cond-depend on 
    "local-ws -> xfonts-base" where local-ws is a "key" package
    installed on stand-alone machines).
   It would also help the i18n teams ("why is not kde-i18n-mylang not
   installed by default????"), help improving CPU optimisations (install
   "k7-opt" key package and all optimised libs for your machine will be
   installed when you install the particular program).
 
 - Rating should be done by surveys, and idealy not by the package
   maintainers (who knows about their ego...). Some independent task
   force would evaluate those surveys and decide which packages get a
   better value than others for the particular task.

   For endusers, it means that they can specify their system, and then
   set minimum level, either fullfiled by each flavor rating or by the
   sum of them all.

   Goal: end user only sees 500 packages that are relevant for him, not
   12000, and distributors may create some specialized distribution sets
   easier.

Gruss/Regards,
Eduard.
-- 
Für einen reinen Wissensgewinn ist ein Notebook nicht nötig.
		-- 1. Krügersche These, oder so

Attachment: pgp7iOTzeBV7u.pgp
Description: PGP signature


Reply to: