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

Re: "dselect" replacement team

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

Much has to be done... I'm in the process of creating a list of them...

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

I object.  I don't think you can easily correct the status file after
a failure with "vi /var/lib/dpkg/status" if it is not a plain ascii
file.  This is a feature which I have needed several times - and normally
I am careful with my systems...

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

If one wants to have one, he shall see one, but I agree it would be much
better if we could shorten the list for normal actions. :-)

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

Oh, so I have always misused it... 

> 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

	Which includes an own tar creater - and the tar extractor has to
	be extended, too.  It cannot handle long filenames...



Individual Network e.V.                _/            OrgaTech KG i.Gr.
joey@office.individual.net            _/              joey@orgatech.de
Geschaeftszeit: Di+Mi+Fr, 15-18 Uhr  _/            Tel: (0441) 9808556

Reply to: