["Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>] Re: apt-get
Anyone care to comment?
------- Start of forwarded message -------
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14623.25752.865309.559503@turnbull.sk.tsukuba.ac.jp>
Date: Mon, 15 May 2000 11:44:40 +0900 (JST)
To: karlheg@bittersweet.inetarena.com (Karl M. Hegbloom)
Subject: Re: apt-get
References: <86vh0lpr43.fsf@megalith.bp.aventail.com>
<87zopwcq5u.fsf@bittersweet.intra>
<86r9b8os34.fsf@megalith.bp.aventail.com>
<87ln1f81bm.fsf@bittersweet.intra>
<14622.19814.312257.704001@turnbull.sk.tsukuba.ac.jp>
<87u2g0oe42.fsf@bittersweet.intra>
>>>>> "Karl" == Karl M Hegbloom <karlheg@bittersweet.inetarena.com> writes:
>>>>> "Stephen" == Stephen J Turnbull <turnbull@sk.tsukuba.ac.jp> writes:
Stephen> Furthermore, the *BSD crowd prefers software that can be
Stephen> forced to work by a savvy administrator, unlike the
Stephen> Debian install stuff, which when it refuses to work can
Stephen> be remarkably hard to unravel. (Eg, I just wasted half
Stephen> an hour purging diald ... diald.postrm was puking
Stephen> somewhere deep in the bowels of debhelper without any
Stephen> error message.
Karl> Did you report the bug? If it goes unreported it may not
Karl> get fixed as quickly.
No, I didn't report the bug. My experience with reporting Debian bugs
has been unpleasant; Debian maintainers I've dealt with generally seem
to believe that the policy manual supplies all the humility needed, so
they're free to be as arrogant as they like. (It happens that all the
Debian bugs I've reported have been due to hasty, poorly understood
Debian fixes, not marked as Debian-specific, of arguable bugs in the
upstream source. Except one, which was in the boot disks, and the
maintainer told me to get the latest boot disks because the bug was
already fixed. So I did, at the cost of a couple hours going through
the whole sequence, the bug was still present, and upon checking the
bug report he cited it was clear it was a different bug. He might
have guessed that I had checked the database since I cited a total of
3 related bug reports in the original message.)
I know I could report bugs and ignore any responses, but it's hard to
convince myself to do that. One of these days I'll psych myself up
for it, and go through my Debian-bug notes and submit them all....
Sure, Debian is a volunteer organization, but many maintainers seem to
see that as an excuse to slack on quality; you see, they're so busy
with "features." :-(
Stephen> This kind of thing happens about once a week....)
Karl> Hmm. XEmacs crashes when I pop up a popup menu then click
Karl> outside of it. This sort of thing happens about once a CVS
Karl> update. :-)
Of course I expect brokenness in the unstable tree! The difference is
that with XEmacs you usually get a backtrace (two, in fact), and when
you don't that is considered a showstopping bug (even when running
under gdb allows you to get a sensible backtrace). Improving error
reporting has been a constant background theme on XEmacs Beta for the
three years I have participated.
The reason I originally moved to Debian was that the install scripts
were located in a standard place and written in POSIX sh or perl (a
step backward, IMHO, but forgivable given the additional power, at
least it wasn't slang) as compared to Slackware (no standards for
install scripts) or RPM (written in a language useless if you don't
create RPMs). This is no longer true; Debian install scripts are
written in a private language "debhelper" whose syntax is arcane and
which is full of bugs, but empty of debugging assistance. It is no
longer possible to step through a Debian script from outside of a
FrontEnd (WTF is a front end and why do the scripts require them, in
fact start them up if they're not present?) The scripts call
debhelper modules which are located who knows where. The many
comments that debhelper adds don't say anything about these things
("no user-servicable parts" I guess).
Again, XEmacs provides a contrast, simplifying and streamlining the
package locations, making several (often unsuccessful) experiments in
offloading feature provision (eg, image handling) to externally
maintained libraries, and continuously (at a low level of activity,
admittedly, but it's something the core maintainers have always
emphasized in their own work) working to clarify and document internal
interfaces.
So much for good reasons to choose Debian. Inertia (and nothing else
is much better) is why I continue to use it.
Debian also used to be a lean distribution that installed a base
system and only stuff over and above that the admin asked for plus
dependencies. Now Debian is as bloated by default as any of the
others, with many bogus dependencies (depends that should be
recommends, recommends that should be suggests---and doc packages
should _never_ suggest the main package; it wastes far more time in
the dselect conflict resolution screen than it saves when you forget
to install the main package---a missing executable is an easy error to
daignose and fix!). Nor did it change configuration except on
explicit request from the admin. But now...
There was a brief power out last night; when I came in today, all of
my workstations booted to fvwm2, when my preferred wm is windowmaker.
Somewhere over the last few updates fvwm2 silently (IMO offering to
change the configuration as the default option in the middle of
upgrading 150 packages is "silent") substituted itself as the
preferred wm. And configuration of _all_ daemon services should be
saved until the very end of the dselect process when the admin has the
time to consider whether and how he wants various services enabled.
Most daemons assume that "if they installed me, they want me all the
time". Well, no, I wanted your _docs_ so I could find out if I wanted
to run you and whether the default would make sense.
Obviously Debian philosophy has changed; I'm not interested in getting
involved in the politics (probably just pissing into the wind), nor am
I interested in debating individual maintainers who think that they
can make judgements about global effects of local code changes on the
basis of a 20 minute debugging session.
Feel free to quote any part of the above.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
------- End of forwarded message -------
Reply to: