dpkg non-non maintainer release
dpkg has just arrived at the top of my worklist. I plan to build and
upload a version of dpkg myself, for a number of reasons:
1. I want to be sure that I can do it.
2. A number of people have reported coredumping bugs, which are really
only possible to investigate for me if I have an unstripped version of
their binary.
3. I want to make sure I know where all the recent changes are and
have come from.
I have a lot of things I plan to do. Near the top of my queue are:
a. Some kind of hook mechanism, which will make it easier to deal with
things like the menu packages. I'll post about my design here.
b. Speeding up parsing of the *.list files and status file. I already
have design ideas, and don't feel the need for any input - I shall
just implement things.
c. Centralise the dependency-handling code, to make it more reusable,
and to make it possible to fix the one or two dependency-related
bugs. This is quite a lot of work, but again, I don't feel I need
much input.
d. Improvements to dselect's ui. Lots of small improvements (grep
the code for `fixme').
e. Improvements to dselect's installation methods, many of which are
quite suboptimal.
Opinions on which of these I should do first ? b is easiest. I think
that a-c should be done by me. d and e could easily be done by
someone else.
Ian.
Reply to: