* 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:
pgp3ii36JDYQy.pgp
Description: PGP signature