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

Re: "dselect" replacement team


On Fri, 11 Apr 1997, Wichert Akkerman wrote:

> Previously Kai Henningsen wrote:
> > Umm. Re-inventing the dependency code in dpkg/dselect?
> > 
> > I thought this was about user interfaces. Re-inventing the dependency code  
> > seems to me a really extreme case of stupidity - and that's putting it  
> > mildly.
> Maybe we should split the dselect effort into two groups: one group to
> design and implement a library with an simple elegant API to interface
> with the dpkg-libraries. This should start with a C-library and could
> later be extended with a C++-wrapper. The second group should work on
> the interface. Using this method it is possible to start with adapting
> the current dpkg-code to the new API. Changes (or new implementations) of
> the library code can then be used as drop-in replacements so no changes
> to the user interface is necessary.

Good idea, but since the UI can literally not be written until the library
has been, not very practical. Maybe a better idea would be to extend the
group after the initial library code has been written, so the original
group writing the library is 6, then is is increased to 9, of which 3
(from the original crowd) maintain the library, and 6 write the

> Seperating the two groups can also improve the library interface since
> the library group probably is more reluctant to add a `hack' to support
> an interface feature.


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