Re: "dselect" replacement team
Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:
> There is only one compelling reason to ever choose C, and this is if you
> do not know C++, or the people who are going to be using your code do not
> understand enough C++ to make sense of it. dpkg-lib is going to be simple
> enough C++ that nothing complex like virtual functions, iheritance and
> whatnot will be a major issue.
Or if your target platform doesn't have a working C++ compiler, as the
Alpha did not until just fairly recently.
At this point, I'm not overly impressed with the direction this team
seems to be heading---it seems to be more oriented towards the ivory
tower ideal of "We'll use all the best possible tools", instead of the
more utilitarian "We'll use the minimum of tools to get our work
done".
Remember, without dpkg/dselect, there is no debian distribution---so
if you make it arbitrarily hard to port dpkg/select, then you've just
limited the distribution's scope.
Nor am I impressed with the apparent attitude towards the existing
code---I've seen a couple of "big rewrite" projects go down the tubes
because everyone wanted to start from scratch.
Any attempt to rewrite dpkg from scratch will either take as long as
dpkg has to get where it is today (in which case it will be far too
late to be useful), or it will miss one of the many subtleties that
exist in dpkg. The only thing that's going to get you a good,
productive tool anytime reasonably soon is by _very carefully_
modifying dpkg and its associated library, testing incrementally, and
then writing some wrappers which encapsulate low-level functions to
higher-level functions.
You can put in some comments, but for this issue I fall in with Ian
and Mark---if you can't figure it out without comments, you probably
weren't meant to modify it. I say this as someone who religiously
comments my own code, and has done bug fixes on dpkg---it should not
be too easy. Period. Some high-level narrative guidance as to what's
going on is fine, but if you're commenting at the statement level,
you're handing loaded guns to children.
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.
And if both dpkg and dselect are truly using the same routines,
where's the risk of dselect hosing something that dpkg wouldn't?
Mike.
Reply to: