Re: Unmaintained Packages
On Tue, 12 Aug 2003, Colin Watson wrote:
> Oh, joy, let's take a stable and generally pretty reliable codebase,
> throw it all out, and write something new because we couldn't be
> bothered to improve what was there instead. What a good idea! </sarcasm>
>
> If you can't tell, I'm allergic to this "let's rewrite it from scratch"
> thing that seems to be popular lately. If you have something good that
> has some problems, don't try to solve those problems by throwing it out
> and starting again! All you'll do that way is come up with a whole new
> set of problems. The only excuse for rewriting from scratch is when the
> old code is unmaintainable, and (on the basis of the small hacks I've
> made to dpkg in the past) I don't see any evidence that it should be
> unmaintainable by competent people.
>
> If dpkg2 is a from-scratch rewrite of dpkg1, I might just have to fork
> dpkg1 and maintain it myself so that I can keep on using it.
It's not a completely from scratch rewrite. The libdpkg.a stuff is being
rewritten, yes, as is all of dpkg-deb. Plus, major parts of dpkg-dev are
being rewritten in python.
The rewrite stuff I'm doing in libdpkg.a is making the system more
maintainable. There are lots of iwjisms in the code, which make it hard to
maintain, fix, add features, etc. Additionally, the new code base will make
it easier to have automated test cases, both on individual functions, and on
the binaries themselves.
The cmdline interfaces won't change. The binary file formats won't change.
But most of the code on the back end *will* be changed.
ps: The test cases will be made from the existing codebase, and will be used
to verify the new code base as being correct.
pps: Watch debian-dpkg@lists this weekend, as I'll be summarizing my plans and
status there.
ppps: Most of dpkg/ and dselect/ won't change, as that code gets hair fast.
Not because it's written poorly, per se, but because it has complex things to
do.
Reply to: