[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "dselect" replacement team


On Fri, 11 Apr 1997, Jason Gunthorpe wrote:

> I have in the past 'cloned' the functions of other programs without having
> the source to them, it is doable, sometimes quite easially. In this case

Witness the GNU project... although source is available for many of the
utilities GNU clones, coders are advised not to look at it, to avoid
copyright complications.

> this is exactly what Brian wants, a clone of dselect with different keys
> and colours :> Half the battle in 'cloning' is duplicating the subtle
> special cases, which can be easially devined by looking at the source..

OK, so I don't know what Brian wants, but here is a brief (!) outline of
how I think the replacement should work:-

I would think it would be a bit more general than "a clone of dselect with
different keys and colours" - a complete re-implementation of the
packaging system so that the user interface is distinctly separate from
the underly mechanisms, which are distinctly separate from the low-level
access code would be very nice.

It could also be made a lot more optimal. For example, as far as I know,
not many packages except for dpkg itself absolutely DEPEND on having the
available and status files as text (menu, dpkg-ftp, dftp? only), so why
not reimplement them as btree-sorted, ultra-efficient files (using
Berkeley libdb, for example), to make things easier. As someone said
earlier, reimplementing the "dpkg" utility itself to be an extra frontend,
rather than a backend to the interface, would fit especially well into
this case.

Part of the inherent "horribleness" of dselect is inherent in the
design. This is also something that needs addressing - Suggests and
Recommends should _DEFINITELY_ be handled differently, there should
probably not be long listings of packages, etc.

Although I hate to say this, I think there is one good piece of software
Microsoft have made. And that is the setup system for all their other
programs. Although it seems now to have become all "wizard" based (trying
to hide complex underlying details never works), the older systems really
did have a good user interface.

Dselect-replacement should also be tailored more for the first-time
installer - at the moment, it certainly seems to be much more tailored for
maintaining a system.

IMHO, another good feature would be a uniform config interface - dcfgtool
or whatever, which does not rely on shell-scripts to ask the user
questions, but instead has its own format of questions. Then pre-install
configuration is available, as is a simple method of copying
configurations between systems. Maybe also a method of copying all the
package selections between machines, then a new machine can be populated
easily, and automatically with a new install of Debian.

One other thing - the development tools will need updating. At the moment,
it there is a following that wants at least the following extra features:-

	* Can be built as non-root
	* Source-Depends

These two features would greatly help the case of having a remote system
build the binary packages from source, where only source is uploaded. We
should also integrate the dpkg-cross support into the development tools to
allow this.

There is also a case for having original upstream source as part of the
Debian source package - PGP-signed md5sums (or whatever) can be used by
any non-trusting party to check the validity of our source.

> It should be a very interesting project!


When (if :-) this is finished, Debian's installation process will
certainly look really nice. For example, say that a sysadmin wants to
install several machines with simple configurations and the same packages,
all he has to do is put the configuration and package-selection files on
the network server, then run the setup program from the CD (or boot the
disk), select automatic install, tell Debian about the network and the
server, and everything is done automatically.

- -- 
Tom Lees <tom@lpsg.demon.co.uk>			http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E  B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)

Version: 2.6.3i
Charset: noconv


Reply to: