Re: "dselect" replacement team
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
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.
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.