Re: Time to rewrite dpkg
Marek Habersack <grendel@vip.net.pl> writes:
> [1 <text/plain; us-ascii (7bit)>]
> * 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
Also I'm sure bootdisk won't be a problem. They need a bit tweaking
around to fit more onto them, but if theres not enough space on one
disk, take two. There should be space on the drivers disk anyway.
> 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.
For cases like your pool, have a look at
ftp://mirjam.informatik.uni-tuebingen.de/debian/*
If you install Debian often, this proposal comes in real handy, cause
you can configure one host and clone that config across a pool.
> > 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.
Yeah, but C programs can be real ugly dirty bitches as well. Also you
can write C in C++ if you like, so everything speaking for C speaks
for C++ also. With C++ the compiler is more strict and can do much
more error checking, especially when using OO design and well designed
classes.
As to the binary problems, you have the same with any language. Just
look at the libc5/6 transition or glibc2.0/2.1 problems.
I like the idea of using C++, because I know it and I know how to
write well structured and clean programs in it. To me it has a nice
look&feel, if one can say that about a language.
>...
> > 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.
So you have 100K dpkg-lib + 35 K prog + 500 K libc or what? I think
350K is quite small, probably smaller than it is now.
>...
> 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
The most important reason to use C++ is that he wants to. Also C++ has
nice OO features that are dirty in C. In C you would have to care
about pointer conversions to get propper OO features, why not let g++
do the dirty stuff and do extra error checking for us.
> 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...
Thats what he is talking about aktually, or at least thats what he is
thinking.
>...
May the Source be with you.
Goswin
Reply to: