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

[Stephen J. Turnbull]

>>>>> "Andrew" == Andrew Suffield <address@hidden> writes:

    >> What is debconf all about, then?

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

OK.  In practice, I don't personally "see" benefits from your four
purposes (I do a full install maybe once every 12-18 months, and I
don't trust anything to do with Japanese enough to do an unattended
install), except consistent UI is always nice.  But definitely they're
really useful for a *lot* of admins, and quite general.

    >> And defoma?

    Andrew> Unmaintained for ages, which hasn't helped. It also
    Andrew> happens to suck.

Why does stuff like that get in?  :-(  I'd really rather see a fascist
Debian-Font-FHS than all those weird symlinks in /var/lib/defoma.

    Andrew> Note that debconf is merely an interface layer; questions
    Andrew> are asked by *packages*.

Ah, that clears things up a lot.

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

    Andrew> No idea what's going on there.

I've taken a closer look, and I think it's political (I'd managed to
keep an old gs-aladdin-vflib installed for a _long_ time).  My best
guess is that something took exception to the old version of gs, and I
allowed an upgrade, forgetting why it was on hold.

Actually, things worked out well, 6 hours later I now have a bleeding
edge Ghostscript with a disabled glyph-cache, three bugs in their
bugzilla, and good-looking Japanese output on the boss's desk, and
"Hallelujah, I've been to the mountaintop, I'm free" of VFlib (cidfmap
Ru13z!)  :-)

Not to mention a shot at the $500 bug bounty, since at the moment I'm
the leading expert on the glyph-cache bug.  ;-)

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

    Andrew> Don't know what you're referring to.

Whatever it is that when it installs a new config file allows you to
look at a diff between what you have on disk and what dpkg wants to
install, before it does anything.

It would be really nice if an aptitude (or whatever) session left the
equivalent of "tla what-changed --diffs" behind.  Better yet, if
/etc/{arch} and maybe /var/lib/dpkg/info/{arch} existed, and debconf
used tla to record past configs.  :-)

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

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

Since you ask ... hm ... it's boilerplate from /usr/sbin/update-inetd,
displayed directly by the script.

[On kneecapping bletcherous config scripts]

    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?

    Andrew> dpkg-divert is part of dpkg, a pretty fundamental
    Andrew> component to a

Sure.  But how am I supposed to know it's _safe_?  Maybe instead of
diverting to /bin/true I should divert to /bin/false?

[On evile code in Debian support]

    Andrew> debconf [...].  There are a fair few hacks involved to
    Andrew> make it a drop-in solution.

Ah, that makes sense.  You'd never be able to get it to propagate
without some effort at making it a drop-in win.

    Andrew> debhelper, which I presume you are referring to, is a
    Andrew> suite of tools to aid Debian developers in creating
    Andrew> packages.  It has an excellent set of manpages; looking at
    Andrew> the code is not necessary unless you're trying to add a
    Andrew> feature,

Or fix something that's broken, or understand why the behavior you see
doesn't look like what's in the manpage.  I was having a problem with
"debian/rules binary" for Coda, and ended up removing the binary-indep
dependency from binary.  Never did figure out why the build broke when
it got to the empty binary-indep target.

    Andrew> I'm not sure why you brought it up.

An example of a Debian tool that I may have had problems with (could
have been make, too, but there were messages from debhelper that
indicated debhelper was confused) that had impenetrable code.

[Re: XF86 configs.]

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

Ah.  They're not installed on my machines for some reason.  Now the
lack of hardware sanity makes sense.

And you're right that XFree86 -configure is suboptimal.  But I get an
X server up.  I think my notebook did get the server up
(suboptimally), but my other Gateway box and an ASUS box did not.  The
problem was that the monitor timings were totally wrong, and I ended
up with no screens.  Now I know why.

    Andrew> Also, you asked for this. You said "yes" when it asked if
    Andrew> you wanted to generate a config file this way.

You're darn right I asked for it; in fact, I very carefully moved *my*
XF86Config out of the way so dexconf would have a clear field to play
in.  (I've been doing this for years when I see X about to be upgraded.)

But it turns out I was missing the hardware detection prerequisites.
I'll have to check if that's somehow something I did, or is a bug.
(IMHO, the config process should check for those and bitch if you
don't have them, like "maybe you really don't want me to just guess".)


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.