[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Time to rewrite dpkg



* Aaron Van Couwenberghe said:

> 	Notably, I'm going to be writing it in C++. This will add about 270k
> to the boot disks' root image, but as the floppy install methods are for the
> most part phasing out under the shadow of easier methods, I'm not going to
Are you sure about that? If yes, the you probably don't install debian very
often. In serveral places, including my own company, which have a few linux
workstations and at least one server I like to put the Debian dist CD into
the server, mount it in the anon ftp tree and install/upgrade the
workstations using FTP - that way I can cut down on costs of the equipment,
I can simultaneously install linux on several machines - from ONE source
instead of having a dozen copies of the Debian CDs. And, yes, I install from
FLOPPIES - now you're telling me the new dpkg won't fit on floppies, right?
It won't sell... as I'm sure I'm not the only one installing Linux on
workstations this way.

> 	Why C++? Well, personally, I have been seeing all of these
> applications pop recently that are for package management, aside from dpkg.
> Examples include dconfig and apt. Other ideas have been floating about, like
> source dependencies and binary diffs.
What does it have to do with the actual code? Language chosen is mostly a
matter of preference, more often of compatibility and compactness of the
produced code. C++ doesn't have the two latter issues... Take a look at
what's happening with egcc's support for C++ - it's constantly gaining new
features, according to the official standards - to name only one, rtti.
Every new language feature in some way changes the way of mangling C++
names, and RTTI will also add entry points for various checking procedures
etc. And you will surely have compatibility (binary) problems as the time
passes.
And code is as good as it's structure and design and not the language used.
C programs can be constructed in a very clean, modular and extensible way
and they still remain COMPATIBLE and COMPACT.

> 	I say that most of these applications would benefit greatly from
> having access to all of dpkg's functionality and variables, so nobody has to
> reinvent the wheel. I want to make all of these a part of dpkg.
This also dosen't justify the selection of C++ as the language... On the
contrary - I'd reccomend NOT to use C++ to create the shared components of
dpkg. Remember, most programmers program in C for various reasons, not the
very least of them being compatibility. Also, C has the nice feature that
libraries written in C can nicely be linked with programs written in almost
every other popular language - be it interpreted or compiled - perl, tcl,
java, javascript, C++, lisp, scheme - you name it. Most of those interpreted
languages have interfaces to use C as the extension language, while they
DON'T support (nor they ever will, I presume - again, compatibility) C++...
So, if you want't your new dpkg be really extensible, modular and modern -
do it in C, but do it it a cleaner way.

> called modular software, and we have this capability in linux today. dpkg
> should be able to accept addons at runtime, or to override default behavior
> by a configuration file explaining where important methods exist.
Again, C does it for you, C++ isn't really useful here.

> 	Consider the benefits. First, dpkg comes as a 350k executable,
> containing nothing but basic logic for commandline arguments and a static
> link of libstdc++. Apart from that, libdpkg is required for dpkg to function
> properly; This library defines all behavior for operations on packages and
> the package/status databases.
And you call a 350k monster a BENEFIT?? If you have a shared library with
ALL the functionality in it, then the DRIVER executable can be as small as
35k - and that's what I call a benefit. Plus, you can do it in C, you can't
in C++ - the latter will always be much larger.

> 	Now, consider: If I want dpkg to be able to install files via http,
> I can just plug in the appropriate module and supply the necessary
> arguments. Now, consider if apt were a module: both dpkg and every frontend
> written for it would inherit functionality for all available file retrieval
> methods. This would eliminate much of the kludgery involved with coming up
> with installation methods for dselect.
Once again, this doesn't justify C++... All of this can be done in much
cleaner (binary-wise) way in C. Also, you even once didn't mention any
feature that's C++ specific and that would justify selection of C++. If you
were talking about a hierarchy of classes, encapsulation, polymorphism -
then you would justify C++ as THE language for dpkg. I can imagine a
hierarchy of classes, each of them designed for a specific task, each of
them deriving features from it's parents - and all that in a modular way.
Yes, that can be done - but why? It can be done in C equally well...

> 	Consider again something more complicated, like bindiffs. Supplying
> the appropriate arguments (--unpack-bindiff --retrieve-bindiff) would cause
> dpkg to load the 'bindiff' module to override every bit of unpacking and
> retrieval logic. Then, apt and all dpkg front ends would automagically
> recieve this feature! This is the beauty of polymorphism in OO design.
And a beauty of a well designed binary interface with a well designed
plug-in interface... in C

regards,
  marek

Attachment: pgpOHSQPLkyum.pgp
Description: PGP signature


Reply to: