Dselect Rant [Was Re: How much space needed for a web server install?]

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Jack" == Jack Morgan <jack@example.com> writes:

    Jack> On Wed, May 09, 2001 at 12:13:41PM +0900, Stephen
    Jack> J. Turnbull wrote:

    >> For some reason dselect gets slower and slower, but the
    >> functionality never improves.

    Jack> I don't know why so many people complain about Dselect. I've
    Jack> never had a problem, that patience didn't solve! Sure the
    Jack> Perl5 hangup caused some frustration but if you just remove
    Jack> all those dependencies your fine.

Well, there was the period of time around dpkg 1.3 when DQ didn't
work didn't work at all.

As for the current state of dselect, there really ought to be a way to
tell dselect _not_ to delete anything for dependency reasons, or
better yet, to query the admin.  This has been needed for 3 years, it
is imperative with 7000 packages available.

It should be possible to say "this package has had broken dependencies
for over a year, do not ever deselect or remove it unless I
specifically say so."

dselect still confuses dependencies of the package versions it wants
to install with dependencies of the package versions already installed
in some situations AFAICT.

It should be possible to configure "I want to watch these packages.
Don't offer me any new packages, or to upgrade any others."  Then the
upgrade screen just tells you that (1) there are NN new packages, and
(2) there are NN updated packages, and (3) here are updates to
packages you are watching and their dependencies.  Again, 7000
packages makes this imperative.

It should be possible to say "I do _not_ want recommended packages
autoselected, I consider that to be tying and I will sue your butt in
Federal court for the antitrust violation" and get some respect from
dselect.  For heaven's sake, there are itty-bitty libraries
(gettext-dev?) _recommending_ emacsen!

It should be possible to say "nobody seems to be running lintian, so
drop me in a editor with /var/lib/dpkg/info/$FUCKEDPKG.postinst set up
in a buffer when the config stage fails and I'll hack it off myself."

It should be possible to offer suggestions like these to the Debian
people and get room temperature responses.  But they'd rather make
excuses for their lack of discipline (which I sympathize with, it's
hard to manage a software project) rather than create tools and
policies to deal with it.  (To be honest, I haven't tried in a while,
so maybe it's better now.)

Debian is still my preferred distro, but it does have its problems,
especially with package management and maintainer discipline.


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