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

Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?)

On Sun, Nov 30, 2003 at 10:07:08AM +1100, Zenaan Harkness wrote:
> On Sun, 2003-11-30 at 05:18, Javier Fernández-Sanguino Peña wrote:
> > On Sat, Nov 29, 2003 at 12:38:29PM +0100, Benj. Mako Hill wrote:
> > > > The (3) part is not something that debian-desktop will do since it
> > > > boils down to modifying, at leisure, the system's configuration
> > > > (/etc directly, since there is not a single point of configuration,
> > > > debconf is not an option here).
> > > What we *can* do is find the ways that we, as a custom distribution,
> > > want to change the configuration files of other packages and then
> > > submit wishlist bugs with patches adding low-priority debconf
> > However, we are currently viewing debconf as a way to do a
> > _minimum_ configuration of packages. Debconf overuse is usually
> > reported as a bug.
> Is this seriously the case?

I tend to agree with Steve Langasek's evaluation of the situation.

> If so, can someone please explain low priority to me - isn't it a
> desirable feature to have a common configuration DB??? Anything
> else just -feels- like it's not The Right Thing.

Right. Low priority questions will not be asked in any default (or
sane) situation. AIUI, you can also have a Debconf question that is
simply never asked (it just checks the DB to see if there is a value
preset). Either (and often both) of these solutions seems well suited
to solving Custom debian distribution's problems.

It seems to me that the major problem is asking people lots of
unimportant questions during installation, some of which they don't know
how to answer. We're not talking about asking people *any* questions
until they're the sorts of people that set their Debconf threshold to
low in which case they deserve whatever they get. :)

> > I might be wrong or things might have changed. Notice, also that 
> > debconf is not even policy so package maintainers can still provide 
> > interactive package installations that depend on user input w/o using 
> > [1] Policy (3.10.1 Prompting in maintainer scripts) says "should" not 
> > "must", so not using debconf for interactive installations is a bug, but 
> > not an RC bug.
> No one said it was.
> And note, Mako wrote "submit wishlist bugs". Which sound appropriate for
> given debconf's current "should" status.

When I was referring to wishlist bugs, I was thinking more against
packages that already use Debconf (or perhaps haven't bothered to add
this sort of configurability in any way yet). Now if there is a
package that doesn't use Debconf but "should," that's a whole other
bug and, quite honestly, it's probably one that's already been
filed. Filing bugs that the package maintainer can not realistically
fix (e.g., add this Debconf question to this package that does not/can
not currently use Debconf) doesn't seem particularly productive. :)

In these sorts of situations, Custom distros need to talk to the
package maintainer and then perhaps offer a hand with the
Debconfization or, if there are no other choices, temporarily do
something that policy forbids in the Custom distro's non-official
Debian package(s).

A "must" for Debconf in policy would, of course, be helpful and I
imagine that this is a conversation we can have sometime after sarge
is released.

> It feels important to having Debian have a consistent [G]UI for
> installation, supporting these live CD things as is being discussed,
> and just being *sane* from an end user's point of view (when you
> have to deal with 13,000+ packages, surely you want to *completely
> eliminate* multiple forms of package configuration - it's the only
> scalable solution (and debconf (or something like it if it is so
> deficient that you are motivated to write a replacement) can have
> multiple backends, multiple front ends etc, so we still have
> customizability, etc)).

I guess what some of the custom distro folks are suggesting is that it
will be useful not just in terms of scaling to manage many packages
but scale to manage single packages in many ways.


Benjamin Mako Hill

Attachment: pgpJOUHQ9JhIe.pgp
Description: PGP signature

Reply to: