dpkg/dselect changes needed

[Ian Jackson <ian@chiark.greenend.org.uk>]

I have been reading this discussion with, ahem, interest.

I stopped doing major amounts of work on dpkg in mid-September, and
told everyone at the time that this would be the case.  That was 5
months ago; I expect to be fully back on-line within the next two
months.

I don't think that me taking a `holiday' from core Debian development
for around half a year should have caused all these problems.  In
particular, I can't see how this should mean that we should abandon
dpkg.

About a year ago I had a choice between spending my time on a new UI
for dselect or the new source format.  I decided to do the latter
because it seemed to me to be more the core activity - user interfaces
can be changed more easily than central data and code formats - and
because it was practically essential to get our porting efforts off
the ground.

I have spent some time communicating with people about various
improvements that might be made to dpkg and dselect.  I don't think
it's fair to lay their lack of progress at my door.

My position has always been that while I've not had time for coding
I'm quite happy to give assistance and advice, and also to help with
architectural decisions.

The separation of the dependency checking code in dpkg and dselect
into a single routine with a moderately clean abstract interface is
definitely necessary but will be hard work.  There are complex design
issues involved, as well as complex coding.  If the project has a
highly competent C programmer whom I can trust to do this right I'd be
quite happy to discuss with them (peer to peer, not boss to underling)
what needs to be done and let them get on with it.

I've deliberately drawn boundaries between various components of the
packaging system.  For example, dselect installation methods and
selection interfaces have a fairly small interface to the rest of the
world.  I'd be quite happy for more contributions to be made in areas
such as these.

I'm also quite happy for someone else to write a debmake replacement,
if I feel that the design and implementation will be done well, and I
think this can be achieved by discussing the questions involved on
debian-devel first.

You seem to have the impression that I've been getting in the way of
things by being critical of various proposals on a technical level.

Perhaps this is just a conflict of ways of working: I find that good
design comes from people discussing with each other how to achieve
their objectives.  I find that discussions where all the participants
agree to start with are usually unenlightening, and their results
should be treated with caution - often it just means that the real
problems with the proposals just haven't been foreseen.

Technical criticism of a proposal, therefore, is to me often a
strategy for improving the proposal.  If I criticise a proposal it
doesn't mean I won't like the next version.  For example, wrt
selection-time configuration I have never categorically stated that I
think it's unnecessary or impossible; I just raised certain questions
I felt were important.  Those questions have now been answered, as far
as I'm concerned, leaving me convinced that this is a way forward.

I also don't think it's fair to say that I've only been negative.  I
have been positive about many things - often I have responded to
suggestions of the form `shouldn't dpkg do XYZ' with `yes'.  Perhaps
you just don't notice those because they don't cause flamewars, or
because I didn't say `right, you, Jonh Smith, go and do it'.

Ian.


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com