Re: "dselect" replacement team
On Mon, 14 Apr 1997, Chris Fearnley wrote:
> 'Jason Gunthorpe wrote:'
> > 3) Many of the fixes require an indepth understanding of exactly how
> > all of the portions work together and interact. A quick way to get
> > this in this case is to simply chuck it and redo it.
> Although I agree with your criticisms of dpkg/dselect, I think simply
> chucking it is a /very/ bad idea. dpkg/dselect embodies some three (?)
> years of experience evolving the most advanced package management
> software on the planet. Since it is such a pioneering work, it has
> rough edges and does need to be redone. But it needs to be redone by
> someone(s) who appreciate the evolution of cutting-edge, complex
> software and understand software engineering enough to glean the ideas
> from the code (poor as it may be at times) and to improve it in a
> careful controlled fashion.
Okay, as I have said before I have worked on alot of projects like this,
some Grand Master Guru has created this awesome code that has a sucky ui
(Sometimes just cryptic) and possibly poor internal structure. It
eventually reaches a point were someone says 'Hey we want -bleck-' and our
guru goes, 'But.. I can't do that <easially>'. So they decided a rewrite
of the major portions is required. I then start working on that and find
that the base code isn't quite flexable enough to do some things the new
UI wants. Talk to the guru, uhu he agrees, try to find a nice elagent
solution, uhu he agrees. Woops, we have to make large scale changes to the
-STRUCTURE- of the code. The major portions of it might be exactly the
same but how the interact is quite different.
I have done this at least 3 times now, it's kind of a neat really ;>
So I ask, is dpkg any different that the above now? Tomorrow? In 2 years?
BTW, when I say 'chuck' I mean chuck the old structure of the