Re: "dselect" replacement team
On 11 Apr 1997, Kai Henningsen wrote:
> jgg@gpu.srv.ualberta.ca (Jason Gunthorpe) wrote on 11.04.97 in <[🔎] Pine.A32.3.93.970410234618.90060H-100000@gpu5.srv.ualberta.ca>:
>
> Umm. Re-inventing the dependency code in dpkg/dselect?
Not just that, the whole mess. Is actually what I would guess will be
done.
> 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
> mildly.
> No one seems to have pointed out any design flaws in that part of the
> code. Prettying it up, doing some fixes, ok - reinventing it, what on
> earth for?
Have you looked at it?
The main reasons I can think of are:
1) It's not very modular, we can rip bits of it here and there, but
those bits rely on structures provided by other bits and so on. You
end up with GOBS of old code.
The actual 'dependancy' code is buried in there some place, I think
within the dselect portion, I'm not sure.
2) The code is -NOT- documented. There are no comments, no description
files, function headers -NOTHING-. It would take a person several
days at least to mearly deduce what each funtion does, let alone
how they interact.
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.
4) To create a library of the dpkg code that can be used by others.
5) It's small enough to be resonable. Dselect and it's library is
only pushing 7k lines (Most in curses code).
6) C++ anyone? :>
If the original coder had said 'You know, I think people would like a nice
library they can use' then we would have had libdpkg and some nice
documentation for it and already have an X11 gui. But that wasn't done,
the code in dpkg seems to work, but it isn't really super elegent.
Probably the most prominate reason is that someone (was it me or Brian? I
forget) suggested that we should make an underlying class library to use
with all the various UI's that people are dreaming up. To do this
correctly would at least require retrofitting the old C code onto some
kind of C++ thing. In my experiance that gives bad results.
So I would suggest 2,3,4 are the most important reasons why.
Jason
Reply to: