Re: time to rewrite dpkg
Hi,
This mail is ignoring Aaron's request for peace over this topic, but I am
not the person who can keep silent if there are obvious mistakes to point
out.
On Thu, May 20, 1999 at 12:39:39AM -0400, Dan Nguyen wrote:
>
> Well your subject says it all "Time to rewrite dpkg." I'm assuming
> that you want to completely rewrite dpkg as a replacement for the
> current dpkg. A sort of dpkg2 persay. If your dpkg does eventually
> become the new standard, then the language you decide to use is very
> important.
Think of egcs. We really should be happy that someone is actually deciding
to work on our package managment. Even if Aarons dpkg will not be the one
used in future Debian releases, it will have affect on the current dpkg.
Everyone should be upset about the current state of dpkg. The reason we are
not is because w are frightened, too.
> > The interoperability subject isn't really a big issue; the base
> > libraries could still be done in C for all I care, and I may just do so. But
> > C++ is compatible with C, and as such anything that can be wrapped into C
> > can be wrapped into C++, or vice versa. In addition, we have CORBA, which is
> > extremely friendly towards C++ implementations, and much more powerful than
> > common interop mechanisms with conventional languages such as RPC.
>
> IMHO. What the best thing to do is write your libdpkg in C. Remember
> C is still the standard language for Unix.
dpkg is not Unix. Do I have to say more? Dpkg is a package manager, and any
language can be chosen. If Aaron had said he would write it in Scheme, I
would have applauded it. If you tell me you want to write one, too, but in
Pascal, more power to you.
Of course, I am exagerrating. There are pros and contras for any language,
but it is silly to rule out anything beside C for historical reasons.
> And it will also allow a
> larger number of languages to possibily use those library calls.
Who will write all these programs? Will you? The current libdpkg is written
in C, how many programs use it? If you say, that YOU are going to write
something in a language you need support for, you would have a point.
> It's your
> project and you can do what you like, but I believe that libdpkg
> should definately be written in C.
Of course, you are entitled to your opinion. But the decisions are made by
people who to do the work.
> If you want to use C++ for he actual dpkg, then you can make C++
> wrappers around libdpkg for that.
> C++ has problems, its size is one
> of them.
The size of the language or the size of the binaries?
The language was carefully designed to avoid bloat of the binaries. C++ does
not enforce any language feature on the programmer. The biggest size concern
are exceptions. But exceptions will make error handling oh so much simpler
and cleaner. About 50 percent of code is error handling. Use of exception
can reduce the amount of actual program code tremendously, which does
decrease the size of the program code (hence the binary). AND it is easier
to understand.
Did you take a look at the error handling code of dpkg?
Use of the standard library is another point. The standard library makes the
program code easier, and really does not increase the overall code, because
if you don't use it, you have to replace it with your own code, which is a
source of errors, too.
> The other is, C++ is in a constant state of flux.
This is plain wrong.
Your knowledge of the C++ language is a few years behind of current
standards and implementation.
Thanks,
Marcus
--
"The purpose of Free Software is Free Software.
The End and the Means are the same." -- Craig Sanders
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
Reply to: