dpkg must never be in C++---Bruce, please rule on this.
I am very worried about some decisions being made for this 'diety'
project (which seems on the verge of overstepping its mandate, but
that's another issue), and I think that some boundaries and policy
must be established.
The single most important issue, I think, is this business of doing it
all in C++.
For this purpose, IMHO, C++ is a mistake. It is insufficently
supported for a basic system tool (dpkg---note that dselect is not
considered "essential") to be dependent upon it.
Remember, Linux/AXP, the _first_ Linux platform port, did not have a
working C++ compiler until its elf support was done, which only
happened about six months ago.
_For the first year and a half of its existence, Linux/AXP would have
been closed to Debian if dpkg/dselect had been in C++_.
If Linux itself is running, we're assured of a C compiler---there is
no such guarantee for C++. Do we want to take the chance of being
locked out of other new platforms? What about
Not to mention the fact that g++ has always been more unstable and
fraught with bugs than gcc.
The second issue seems to be the scope of the project itself.
While I support the goal of making a libdpkg and such, I think the
team for that should consist of Ian Jackson and at most two other
people, with the possibility of "outside specialists" for creating
interfaces to scripting languages, etc.
For the moment, I think any dselect replacement must use dpkg, until
the interface/backend split can happen.
So what does our benevolent dictator think?
Mike.
Reply to: