Re: Is it time to abandon Dpkg?

[Craig Sanders <cas@taz.net.au>]

wow! go away or a few days and come back to find that the death of
debian has been proposed (and by the project leader, no less!)



On Sun, 22 Dec 1996, Ian Jackson wrote:

> On occasion people have asked me, why doesn't Debian just use the .rpm
> package format ? The answer to this is: .deb is more powerful. It has
> more kinds of dependencies and more kinds of maintainer/installation
> script.

imo, redhat's user interface isn't great either. 

i really dont like their control panel (nice idea but it only serves to
obscure the underlying config files and mechanisms which it manipulates)
or their rc.d & init.d style or the way they handle modules (e.g. no
/etc/modules file).

customising anything or adding a feature not explicitly catered for
(e.g. i had to add eql load balancing to a red hat system a few weeks
ago) means breaking the standard and setting up something which is
incompatible with the control panel - step outside it's limits and you
can't use it again for fear it will break what you've set up.

(now part of this may be due to my relative inexperience with redhat
versus debian but a lot of features and just plain common-sense that
i've come to expect with debian seem to be missing entirely from redhat)

we have a chance to do this right with the debian-admintool project.
To me, that means providing a user interface which compliments and
highlights the features and the logical connections between subsystems,
not one which arbitrarily simplifies them to force them to fit the user
interface.


all this points out that in many ways, debian is incompatible with
redhat - you can't overlay one on top of the other without a lot of
work. switching from .deb to .rpm will hide that important fact, and
end up with debian vanishing ("it's broken. debian .rpms dont work with
my redhat system. don't use debian!"), and all the better features and
better thought out ways of doing things (the open development model &
120 developers vigorously debating issues produces better results than
half a dozen - debian is to linux distributions what linux is to unix)
will vanish with it.

> Red Hat probably think these are just overcomplications, however, it
> is these features that allow us to do an in-place and/or partial
> upgrade without taking the system right down to do it.
> 
> These arguments apply even more to using rpm to do the actual
> installation.
> 

> Incidentally, providing a program to install .rpm's is a two-edged
> sword: people may choose our distribution because of it, but they may
> choose to release their packages only as .rpm's as a result.

maybe.  

on the other hand, .rpm doesn't have any equivalent to debmake (which
is, imo, one of the most important developments for debian since dpkg
itself!). It makes creating .deb packages much easier than it used to be
and still much easier than making .rpm packages.


> I think it's a great shame that noone has stepped into the breach wrt
> dselect's user interface. I will have (make?) some time after the end
> of January to work on it. I don't think it's a particularly big job
> - I could do a new in time for the 1.3 codefreeze (end of February,
> right ?).

i'm no great programmer (can hack small programs and scripts but my
patience limit is about two or three pages of code) but i am quite good
at designing programs and user interfaces and helping to define the
specifications....and very good at balancing the needs of the novice (it
must be easy/simple and not confuse me) with the needs of the expert (it
must not slow me down, get in my way, or limit me). I'd like to be a
part of any discussions about giving dselect a face-lift.

it is after all, dselect which is the "problem" area. dpkg is fine (in
fact, wonderful)...but dselect is overly complicated for the novice and
it's UI is groaning under the strain of 850-odd packages. Even breaking
the UI up into sections so that you saw 20-50 packages in each section
rather than 850+ in one list would help considerably.

A menu bar at the top of the screen would help too.  Something like:

    File Menu            Section             Actions        Options
      Load Selections      admin               Select         Verbose
      Save Selections      net                 Deselect       Assume Defaults
      Merge Selections     devel               etc ???        Always Help
      ----------------     games                              etc ???
      Save & Exit          x11
      Quit/No save         ...etc...

this is just off the top of my head but should be good enough to give an
idea of another approach to dselect's user interface.

or maybe some sort of folding-editor style or xtree-like approach

> If the Debian project does abandon dpkg it would IMO be the triumph
> of form over content.

didn't you know?  image is much more important than substance :-(

craig


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com