Re: [OT] Re: [Gnu-arch-users] Re: Arch hooks

[Andrew Suffield]

On Fri, Oct 03, 2003 at 12:45:30PM +0900, Stephen J. Turnbull wrote:
>     >> And fixing that is explicitly a design non-goal.  We're trying
>     >> to appeal to the Macintrash/Windoze/GookTK crowd,
> 
>     Andrew> I'm not sure who you're talking about there, but it sure
>     Andrew> isn't Debian.
> 
> What is debconf all about, then?

Debconf has several purposes, all good ones, none of which are what
you describe above. Firstly, some context: debconf is a replacement
for the previous practice of asking questions during the postinst
script.

This practice had several issues, and debconf is the solution to
them. Briefly:

 - unattended installs are now possible
 - the user interface is consistant, flexible, and can be changed
 - the same questions are not asked multiple times when they do not
   need to be
 - questions can be suppressed according to priority

> And defoma?

Unmaintained for ages, which hasn't helped. It also happens to
suck. But the principle is that when you install a new font, instead
of having to run around educating about six different things about it,
you just let defoma know and it will call all the right stuff.

It should be user-transparent when it isn't broken. It's been broken
for quite a while due to a lack of attention. It asks no questions of
the user (at present, anyway); it does not use debconf, although it
did in the past.

> AFAICS from the
> questions they ask, these are deliberate attempts to dumb things down
> to a series of yes/no questions, not to make things sensible.

This happens on occasion, often when inexperienced maintainers first
attempt to use debconf. Note that debconf is merely an interface
layer; questions are asked by *packages*. Packages vary in
quality. Abuses of debconf are not all that common any more.

> Both of
> these regularly get forced on me (in sid) and stuff breaks on a weekly
> basis

That's pretty regular for sid. When somebody screws up with debconf in
a package I use, I go and set them on fire until they stop.

> most recently Ghostscript suddently stopped being able to
> handle Japanese, with no warning and no way to figure out what
> happened.

No idea what's going on there.

> It took years to get the "diff" option added to the debconf
> stuff;

Don't know what you're referring to.

> the next real improvement in that direction will probably also
> take years.  :-(

I generally get responses from Joey Hess within days for simple stuff.

> OTOH, that "if you use xinetd you'll have to port by hand" message has
> been there for a year or more.  I can live with that.

Is that a message displayed using debconf? Sounds like a complete
waste of time, what's it from?

>     Andrew> That should make it go away. There's usually a way, you
>     Andrew> just have to know where to kick stuff.
> 
> And how is someone who hasn't worked on debconf supposed to know?

dpkg-divert is part of dpkg, a pretty fundamental component to a
Debian system. It is unrelated to debconf. The name should be a hint,
although the recent ridiculous pollution of the apt-* namespace has
not been helping matters.

(This is fairly fundamental stuff).

As for how you're supposed to know... well, there's plenty of
documentation out there. It's got a perfectly adequete manpage, and is
mentioned in the reference manual (debian-reference). Asking any
experienced Debian sysadmin, or on one of the large user help groups
would probably have got the right answer.
(address@hidden or #debian on irc.freenode.net
are usually a decent bet)

> Both debconf and debmake (or whatever has all the dh_* tools) are "no
> user servicable parts".  I've hacked a few lines of kernel, I've
> hacked a few lines of Emacs, I've hacked a few lines of Ghostscript,
> I've hacked a few lines of Python, I've hacked a few lines of X11.
> I'm not afraid of big source trees.  But the debstuff defeats me.

debmake is entirely obsolete and was a bad idea from the start. It
must die.

debconf is an utterly evil but fairly small interface between packages
and users, that generally works about as well as it can under adverse
conditions. There are a fair few hacks involved to make it a drop-in
solution.

debhelper, which I presume you are referring to, is a suite of tools
to aid Debian developers in creating packages. It has an excellent set
of manpages; looking at the code is not necessary unless you're trying
to add a feature, which means you're doing active Debian development
anyway. Users have no use for debhelper, and should never come into
contact with it, much like most users will never need to understand
how the xemacs lisp compiler works; I'm not sure why you brought it
up.

>     Andrew> dexconf is a tricky one.  In principle it's a nice idea,

[I'll take these in reverse order]

> What is the dexconf idea?  According to the man page, it's to
> substitute asking an external database for asking the hardware (even
> though according to the manpage it's not a satisfactory substitute!)
> This is a nice idea?

The dexconf manpage is largely irrelevant now, because it reflects
what /usr/bin/dexconf currently does.

I almost wrote the-utility-formerly-known-as-dexconf earlier, perhaps
I should have left that in.

dexconf originally did what the debconf-driven configuration interface
now does. Now dexconf merely takes the values from debconf and writes
out the config files - it's a backend tool.

The intent of the debconf interface is to combine hardware detection
and user configuration in a quick and simple interface. I can
generally get a working xfree86 config file that I don't have to edit
in under 30 seconds.

The dexconf manpage appears to be out of date with respect to the
current state of the debconf interface, which does ask the hardware if
you have the relevant packages installed.

> Really?  I have never seen any utility that can do half as good a job
> as XFree86 -configure does.  On the platforms I have available, of
> course.

Historically, as in around 4.0, it was hopelessly unreliable. dexconf
dates from that era. Its current status is unknown. However, and this
one is very significant:

Debian supports platforms which the upstream authors of xfree86 *do*
*not*, to the point where they will not work at all if you are not
using the Debian version of xfree86. And we don't use
XFree86 -configure at present. So it likely doesn't work on these
platforms. That's not to say that it couldn't be used, but it would be
significantly difficult and of questionable value.

Currently, Progeny's "discover" is used for hardware autodetection,
along with mdetect and read-edid. They seem to do the job just fine,
and I doubt XFree86 -configure would do significantly better; in some
respects it does worse (nothing comparable to read-edid).

What the Debian xfree86 debconf stuff provides that XFree86 -configure
does not is a way to easily configure the things which cannot be
detected. For example, the output on my subnotebook is completely
oblivious to the fact that it has a jp106 keyboard - instead
configuring it for us, which is doubly confusing to me since I
normally use the gb layout, which is different again. It also gets the
number of mouse buttons and the screen timings wrong.

Sure, I could just edit the output... but the time to do this adds
up. The debconf stuff for xfree86 is a contributing factor to my being
able to go from a blank hard drive to a usable system with
mail/X/sawfish/xemacs/toolchain (ie, all I really want to get on with
useful work) in under 15 minutes (my record to date is 11, but that
was a server without X).

>     Andrew> The latest (as in, last few weeks) should be a significant
>     Andrew> improvement,
> 
> Nope.  I've updated twice since Sept 1, and both time the dexconf-
> produced XF86Config wouldn't even boot X.  (I don't know if dexconf
> changed, so it's probably the same bug both times.)

Oh, nothing changed like that. I was thinking more about its handling
of user modifications to the config files.

If it's not working at all then either:

a) you didn't have discover, mdetect, and read-edid installed and
picked the wrong hardware, or else they went badly wrong (unlikely)
b) your hardware is not supported by the X server you have installed
c) you answered some of the other questions incorrectly
d) there's a bug

I really need something more accurate than "wouldn't even boot
X". Presumably you got it to work, so *what* was wrong with the config
file?

Also, you asked for this. You said "yes" when it asked if you wanted
to generate a config file this way. You could always have said "no" if
you wanted to write the file by hand, aided by XFree86 -configure or
whatever else.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature