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...
Regards,
Joey
--
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: