Re: "dselect" replacement team
Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:
> On 14 Apr 1997, Michael Alan Dorman wrote:
> > Or if your target platform doesn't have a working C++ compiler, as the
> > Alpha did not until just fairly recently.
> But it does now, and that is really the point isn't it?
No, that's not the point. The point is _I_---though maybe no one
else---think that the lowest level tool that makes debian debian
should be immediately portable to any platform that Linux is portable
to becaues THIS COULD HAPPEN AGAIN.
> I don't think anyone has ever said we should rewrite everything
> now. If you read some of the msgs between Tom and I without reading
> the whole thread then you might get this feeling. But what we were
> talking about is the possible future directions of the libdpkg, we
> don't want to make some silly decision now and then 4 months later
> say, 'You know, I wish...'
I've read the whole thread. It sure as heck sounded like the
immediate intent was to reimplement dpkg, etc. If you've really got
time to waste, I can get specific cites, but please note that others
have taken your statements in the same way.
Now if I'm wrong, if all you're talking about doing is replacing
dselect, be my guest. If, as part of that work, you come up with
something that makes implementing dpkg2 five lines of C++ code (and
there's a *spectacular* C++ getopts replacement out there, check
comp.sources.misc:44, I think, called options), great.
But don't touch dpkg, please. It needs to be lowest common
denominator.
> So we were speculating what would happen if we did do a rewrite,
> what should the code look like and what should it be doing. I think
> we have nearly finalized that.
If you're not going to do a rewrite, what, exactly, are you finalizing
here?
> > Now, I do disagree with Ian about having dselect still call dpkg---I
> > think that libdpkg should indeed comprise all of the back-end
> > processing that dpkg does, and that dselect (or its replacement)
> > should be using those routines directly.
> You do realize that either requires a dpkg rewrite or make Deity use the
> same interface as the existing dpkg (Which might not be able to handle
> it), don't you?
I think there's a difference between a ground-up rewrite in C++ and
taking the current dpkg source, separating the general back-end
functionality from the interface issues (which will no doubt change
the interface somewhat, to reduce coupling), and then making the
necessary modifications to dpkg and dselect to use the resulting
library.
Now I will concede that there is a possibility that the existing dpkg
code is so non-modular that starting from scratch is preferable. I
often feel that way when I look at the code.
BUT, I think that re-doing it _in C++_ is a mistake. In addition to
the other reasons I've given, I wonder if anyone has any information
on the relative difficulty of interfacing C and C++ to the important
scripting languages (Perl, Python, Tcl). From what I understand, it's
much harder to do in C++ than C. If one of the benefits of having a
libdpkg with a well defined interface is to facilitate that, then
let's not neglect that aspect.
Mike.
Reply to: