Who maintains dpkg?

The Debian project is known for its public brawls, but the truth of the matter is that the Debian developers have not lived up to that reputation in recent years. The recent outburst over the attempted "semi-hijacking" of the dpkg maintainership shows that Debian still knows how to run a flame war, though. It also raises some interesting issues on how packages should be maintained, how derivative distributions work with their upstream versions, and what moral rights, if any, a program's initial author retains years later.

Dpkg, of course, is the low-level package management tool used by Debian-based distributions; it is the direct counterpart to the RPM tool used by many other systems. Like RPM, it is a crucial component in that it determines how systems will be managed - and how much hair administrators will lose in the process. And, like RPM, it apparently causes a certain sort of instability in those who work with it for too long.

Ian Jackson wrote dpkg back in 1993, but, by the time a few years had passed, Ian had moved on to other projects. In recent times, though, he has come back to working on dpkg - but for Ubuntu, not for the Debian project directly. One of his largest projects has been the triggers feature, which enables one package to respond to events involving other packages in the system. This feature, which is similar to the RPM capability by the same name, can help the system as a whole maintain consistency as the package mix changes; it can also speed up package installations. Triggers have been merged into Ubuntu's dpkg and are currently being used by that distribution.

The upstream version of dpkg shipped by Debian does not have trigger support, though, and one might wonder why. If one listens to Ian's side of the story, the merging of triggers has been pointlessly (perhaps even maliciously) blocked for several months by Guillem Jover, the current Debian dpkg maintainer. So Ian concluded that the only way to get triggers into Debian in time for the next release ("lenny") was to carry out a "semi-hijack" of the dpkg package. By semi-hijack, Ian meant that he intended to displace Guillem while leaving in place the other developers working on dpkg, who were encouraged to "please carry on with your existing working practices."

Ian also proceeded to upload a version of dpkg with trigger support, and without a number of other recently-added changes. It is worth noting that all of this work went into a separate repository branch, pending a final resolution of the matter. So when the upload was rejected (as it was) and Ian was deprived of his commit privileges (as he was), there was no real mess to clean up.

Those wanting a detailed history of this conflict can find it in this posting from Anthony Towns. It is a long story, and your editor will only be able to look at parts of it.

One of the relevant issues here is that Guillem Jover appears to be a busy developer who has not had as much time to maintain dpkg as is really needed. Since the beginning of the year, he has orphaned a number of other packages (directfb and bmv, for example) in order to spend more time on dpkg. But, as a result of time constraints, a number of dpkg patches have languished for too long.

While this was happening, Guillem put a fair amount of the time he did have into reformatting the dpkg code and making a number of other low-level changes, such as replacing zero constants with NULL. Ian disagrees strongly with the reformatting and such - unsurprisingly, the original code was in his preferred style. And this is where a lot of the conflict comes in, at two different levels. Ian disagrees with the coding style changes in general, saying:

Many developers will disagree on the value of code reformatting; some projects (the kernel, for example) see quite a bit of it. Judicious cleaning-up of code can help with its long-term maintainability. All will agree, though, that reformatting can make it harder to merge large changes which were made against the code before the reformatting was done. This appears to be a big part of Ian's complaint: unnecessary (to him) churn in the dpkg code base makes it hard for him to maintain his trigger patches in a condition where they can be merged.

Code churn is a part of the problem, but Ian's merge difficulties are also a result of doing the trigger work in the Ubuntu tree rather than in Debian directly. Ian did try to unify things back in August, but that was after committing Ubuntu to the modified code. Ubuntu's dpkg is currently significantly different from Debian's version, and, while one assumes that, sooner or later, Debian will acquire the trigger functionality, there is no real assurance that things will go that way. Dpkg has been forked, for now, and the prospects for a subsequent join are uncertain.

Ian also asserts that, as the creator of dpkg, he is entitled to special consideration when it comes to the future of that package. His semi-hijack announcement makes that point twice. But one of the key features of free software is this: when you release code under a free license, you give up some control. It seems pretty clear that Ian has long since lost control over dpkg in Debian.

So who does control this package, and how will this issue be resolved? Certainly Ian's hijack attempt found little sympathy, even among those who think that dpkg has not been well maintained recently. There are some who say that the disagreement should be taken to the Debian technical committee, which is empowered to resolve technical disputes between developers. But faith in this committee appears to be at a low point, as can be seen in this recent proposal to change how it is selected:

Meanwhile, the discussion has gone quiet, suggesting that, perhaps, it has been moved to a private venue. The dpkg commit log, as of this writing, shows that changes are being merged, but triggers are not among them. It is hard to imagine that the project will fail to find a way to get the triggers feature merged and the maintenance issues resolved, but that does not appear to have happened yet.

---

(Log in to post comments)

One important point that the article fails to mention is that Ian Jackson is a long-standing
member of the technical committee.

Yeah, and the "_ian" part of Debian :-)
[for the humour-impaired: the inclusion of this (obvious, veridical) fact is the joke]

No, that's Ian Murdock

yeah, my bad. dpkg Ians mixup.

The (char*)0 -> NULL varargs change is pretty amateurish and introduces a real, undeniable
bug, as void* is not guaranteed to be the same size as char*, only that it must be the same
size or larger.

I recently had to fix several bugs in a certain open source communications toolkit that took
exactly this form; building on a new architecture caused all manner of weird looking problems
to appear that wasted quite a few hours to figure out.

One of the hardest things I've had to swallow since starting to write code for money is *not*
making cosmetic changes in *obviously ugly* code, because My Style is Obviously Better than
This Piece Of Crap. It's hard, but a professional should understand that the same ego device
that causes him to feel this superiority is the exact same thing that he is trampling all over
in someone else when making stylistic changes of no technical merit to their code.

To me this seems small-mindedly rude, and on several lines of the diffs that Ian highlighted,
more than a little concerning for such a core Debian maintainer to be making this sort of
trivial mistake. I know who I won't be blaming the next time dpkg swallows my hard disk. ;)

They're also adding a specific null pointer constant, nullptr, to the next version of C++ to
make all the "but 0 isn't a pointer" weenies happy.

That's just bowing to the inevitable: virtually every vendor already has 
such a constant, under some name or other (including GCC). You need it for 
non-confusing overload resolution anyway.

(Plus, to be honest, the overloading of the integer 0 with a specific 
pointer meaning, with the unique stipulation that it need not be 
all-bits-zero, with the corresponding `pointer context' stuff, was a big 
mistake from the start.)

To be honest, though, I've introduced this particular bug myself without 
noticing, and so has everyone else I know. The real problem here is C and 
C++ being deeply counterintuitive (even more than usual).

Which part of "don't break code that works, for no reason" is counterintuitive?  (I ask merely
for information.)  

The counterintuitive part is NULL not always being the thing to use if you 
want a null pointer.

Breaking code that works, well, I've done *that*, too, but generally when 
refactoring old and tangled messes. I didn't think dpkg would count (and 
random stylistic cleanups into a *different style than the rest of the 
code*, well, ick.)

In what scenario does NULL not work if you want a null pointer?

Specifically, when doesn't GCC's __null (or equivalent in other modern compilers) do what you
expected a null pointer to do ?

Ah, I think I get it now. So the concern is that on some (now obscure) platforms, there are a
variety of pointer sizes available, and someone might actually be stupid enough to use one
narrower (and thus less general) than void * in a vararg function. At which point NULL (being
void *) will be the wrong size and cause unexplained problems. It seems to me that (type *)
NULL is still a perfectly good choice of value for such a parameter and that we have modern
vararg type checking for exactly this sort of reason, although admittedly that probably won't
warn you about the portability problem if you're testing on platforms where pointers are
always the size of the machine word.

I wonder... is that a -W option to GCC that enables a warning if you try to pass NULL or 0 to
a varargs function where a pointer to some data is expected?

If you mark up the function with __attribute__((sentinel)) then
it will warn.

All common functions are marked up already.

$ cat xx.c
#include <unistd.h>

void f() {
        execl("hello","world","!",0);
}
$ gcc -Wall -O2 -c xx.c 
xx.c: In function &#8216;f&#8217;:
xx.c:4: warning: missing sentinel in function call
$ 

I personally marked up X, GLIB and GTK for instance... :/

Ciao, Marcus

Aha! So that's what that damn warning means!

It would really help if the warning said "missing cast of 0 to varargs function" rather than
"missing sentinal"!

Name a POSIX system, or better yet, a platform on which dpkg runs, where code and data
pointers are not the same size. Using NULL for function pointers is fine given certain
assumptions, and these days, IMO, one can safely make these assumptions. 

Assumptions are necessarily for practicality. You assume that cars will stop at red lights
when you cross the street, don't you? You assume that a char has eight bits, don't you?

Standards are simply sets of assumptions we allow programs to make. POSIX implies that using
NULL, with a sensible definition, is okay for every kind of pointer.

Some assumptions are warranted and others not. It's not warranted to assume little-endian byte
ordering, for example, because the choice is arbitrary and still not uniform. OTOH, it is
warranted to assume that pointer types are the same size because they're uniform ally so, and
because there's a strong reason to think that the assumption will hold into the future.

If you've represented a UTF-8 encoded string with some kind of char array, you've relied on
'char' having at least eight bits.

There is a tradeoff involved in not making assumptions. Say you're writing a portable program
and you don't want to assume AF_UNIX support. You can either use some other IPC mechanism,
likely to be less efficient, or code two versions, one that uses unix-domain sockets and
another that uses something else. Either way, there is an overhead for not assuming AF_UNIX
support, either in runtime overhead or maintenance.

You can add build-time checks of your assumptions, true, but some assumptions hold true so
often that it's often not worth even bothering to check. All I'm arguing is that for
non-embedded systems, all pointers being the same size is the case often enough that it's not
worth it to litter the code with strange casts.

Checking whether the assumption held would be simple enough with something like autoconf, but
there's no reason to clutter the code itself.

   somevarargfunc("these", "are", "some", "strings", (char *) NULL);

Whether C89 requires prototypes or not is irrelevant to dpkg though, as dpkg is using C99.
(--std=gnu99, to be precise.)

It doesn't even hold into the present :(

Can you name an example of a POSIX system for which the assumption does not hold?

Any IA64 or PPC64-based systems. I think HPPA too but can't remember.

(On both these platforms it so happens that data pointers are all the same 
size: but function pointers are larger... and yes this has exposed bugs in 
free software.)

I don't think that's true. See the downthread comments on the same topic. I'd be interested in
knowing what the specific bugs were.

If I could remember, I'd say. I'll have a dig.

#include <stdio.h>
int main()
{
  printf("%ld %ld\n", sizeof(void *), sizeof(int(*)()));
  return 0;
}

8 8

Oh. My memory is failing me and I can't read simulator source code, it 
seems. (I was *sure* they were examples of arches using a descriptor 
consisting of a data pointer combined with other stuff.)

> Assumptions are necessarily for practicality... You assume that a char has eight bits, don't
you?

I think that's called "disproving your own argument by contradiction".

Have two, IA64 and PPC64.

Code and data pointers being different sizes is not uncommon: generally, 
in that situation, the data pointer is a plain pointer and the code 
pointer is some sort of descriptor.

Ah, oops. Forgot about that. (It's tripped me up before, too.)

(I still have memories of pointer sizing bugs in the area of dlsym(), but 
I can't remember what they were.)

> Name a POSIX system, or better yet, a platform on which dpkg runs, where 
> code and data pointers are not the same size. Using NULL for function 
> pointers is fine given certain assumptions, and these days, IMO, one can 
> safely make these assumptions. 

I think you guys are missing the point. The issue is not code vs data pointers. The issue is
ptr vs data. A varargs function being passed a NULL pointer needs to be passed (void *) 0 or
(char *) 0 or some pointer. Passing just a 0 which is legal representation for a NULL pointer
in C does not work for 64-bit systems. 0 is a 32-bit quantity, (void *) 0 is a 64-bit quantity
for LP64 (Unix/Linux) as well as P64 (Windows) 64-bit platforms.

How is what I said "still not it" when it's exactly the same as your explanation ?

"The idea of a "void *" being generic is that variables of type "void *" can store pointers of
any type, and pointers can be cast to void and then back to the original type without
information loss."

As far as I remember it is illegal to convert between void* and any function pointer type in
ANSI C; POSIX' specification of dlsym() actually relies on what is essentially a vendor
extension to work for function pointers.

This is surely related to the aliasing rules, which also have a similar 
special hole allowing aliasing of of void * and char *, but not of 
pointers of any other distinct types.

Is there one real-world POSIX-compliant platform that cares about the distinction?

$ cat -n a.c ; ./a ; uname -sp
     1  #include <stdio.h>
     2  
     3  int main(void) {
     4      printf("%d %d\n", sizeof(int), sizeof(void *));
     5      return 0;
     6  }
4 8
NetBSD x86_64


Same for Linux amd64.

No.

sizeof(int) and sizeof(void*) are likely to be different, but sizeof(void*) and
sizeof(any_other_t*) are the same on every POSIX platform I know about. That's the distinction
without a difference the OP mentioned. You don't need to pass "exactly the right type"
because, AFAICS, the bit pattern of the pointer is going to be same no matter what -- provided
you pass an actual pointer.

Oh, whups :) In that case I do not know the answer.

> the bit pattern of the pointer is going to be same no matter what --
> provided you pass an actual pointer.

This took me by surprise:

int main(void)
{
        int n;
        void *p = &n;
        printf("%p\n", p);
        p++;
        printf("%p\n", p);

        return 0;
}

I thought incrementing a void pointer would cause a compiler error (or at least a warning),
but it seems to treat it as a char pointer and increment it by one byte on my system (gcc
4.1.2 on Solaris).

A GCCism:

     -Wpointer-arith
         Warn about anything that depends on the ``size of'' a
         function type or of "void".  GNU C assigns these types a
         size of 1, for convenience in calculations with "void *"
         pointers and pointers to functions.

The lesson being: when you run "gcc" with no options, it does not compile the C language, but
rather the "GNU C" language.  GNU C bears a strong resemblance to C but has many additional
and alternate semantics.

If you're trying to write portable code and you want gcc to follow Standard C rules, you have
to explicitly request it.  I normally use, at a minimum:

-std=c99 -pedantic -Wall -Wextra

#include <stdio.h>
#define E(t) printf(#t " = %u\n", sizeof(t));

int main(void)
{
        E(void *);
        E(void far *);
        E(void near *);
        E(void (*)(void));
}

/* “Tiny” and “Small” model */
void * = 2
void (*)(void) = 2
/* “Medium” model */
void * = 2
void (*)(void) = 4
/* “Compact” model */
void * = 4
void (*)(void) = 2
/* “Large” and “Huge” model */
void * = 4
void (*)(void) = 4
/* For your information about this compiler, in all models: */
int = 2
long = 4

Not applicable. DOS isn't a POSIX system.

So what? You do not need DOS to make a compiler output far/near-based pointers. What it
requires is — I think — that the CPU is in real mode because that's where far/near pointers
make most sense.

It would be a perfectly valid POSIX system to have 32-bit function pointers and 64-bit data
pointers, for example.

In that case, void* would have to hold 64 bits, but a varargs function expecting a function
pointer and passed a void* would pull 32 bits off, leaving 32 bits of junk for the next
argument to pull.

The reason this bug is so subtle is because systems like that are quite rare.  Up until they
aren't, and then the waste product hits the rotary impeller.

When AMD64 became popular, I ran into *many* of these vararg bugs on my Gentoo system because
developers had become used to passing 0 for NULL.  To my shame, I patched many of these by
passing NULL and only now realize it should have been (char*)0 or similar.

I don't think your scenario is realistic. dlsym() returns a void*, not a function pointer
type, implying that void* and function pointers are the same size. Plus, IIRC, POSIX
explicitly guarantees that function pointers can be round-tripped through void*.

I don't think we have to worry about different pointer sizes any more than we have to worry
about bytes that aren't eight bits wide. Don't litter your code with casts; just use NULL.

C guarantees void* will be large enough to hold any pointer type and automatic type-casting
handles most of the problems.

The *only* places this causes problems is functions without prototypes, which no one does
anymore, and vararg functions.

Since the only place this makes bugs is vararg parameters, it is a very subtle problem indeed.

Another thing that makes these bugs painful:
When I was debugging my AMD64 Gentoo problems caused by passing 0 instead of NULL or (char*)0,
the problems only showed up *sometimes* with -O2 compiles and *usually* with -O3, but never
with -O0.  It entirely depended on what junk happened to be on the stack after the terminating
0 integer and if the junk was 0 or not.

I'm not saying that you should spell "null pointer" at "0", but that it is okay to use NULL
(which should be 0L or ((void*)0) everywhere.

I should have kept my response simple.

No, you cannot use NULL everywhere.  If function pointers and data pointers are different
sizes, a void pointer will be the largest size.  This will cause problems with varargs when it
expects a pointer of the smaller size.

An example with 32-bit function and 64-bit data:
After calling the vararg function *properly* the stack might look like:
 (char*)0xf00fdeadf00fdead
 int(*x)(int,int)0xdeadbeef
 (int)32
 (int)64

But if you call it with NULL for the function pointer it will be:
 (char*)0xf00fdeadf00fdead
 (void*)0x0000000000000000
 (int)32
 (int)64

Now if the vararg function pulls the arguments like this:
 pull char* - 0xf00fdeadf00fdead
 pull int(*x)(int,int) - 0x00000000
 pull int - 0
 pull int - 32

See how the last two int arguments got the wrong data?

Even in the highly unlikely scenario that function pointers someday become _smaller_ than data
pointers (which would have no benefits and which would make dynamic loading exceedingly
complicated and delicate), the vast majority of pointers are still data pointers, all of which
will have the same size.

My point is that in the real world on mainstream systems, you don't have to worry about
contingencies like the kind you mentioned anymore. Embedded, special-purpose code is
different, but then we're not talking about POSIX anymore, and lots of other assumptions go
out the window too.

I don't imagine dpkg is going to run on a microcontroller.

> If function pointers and data pointers are different
> sizes, a void pointer will be the largest size.

No, as noted above C explicitly requires void* to have the same representation and alignment
as char*.  The guarantee that a pointer can be reliably converted to void* and back again
applies only to pointers to object and incomplete types, not pointers to functions.

Another varargs type problem: sizeof() returns size_t, but %d expects an int. You should use
%zu to format values of type size_t.

Hah, I was waiting for that. :)  Seems you can't complain about type widths and then go write
an invalid printf!

... unless you want your program to be portable to any of the large number 
of extant systems that don't support %z in printf(). (Linux/glibc systems 
have supported it for ages, of course, but it's the only system I'm 
writing code for right now that does.)

Ah, so it's OK to sin if it doesn't cause any immediately identifiable short term problems?

Fine, let's define "matter" as "exist".

Which platforms are we worrying about?

All 64-bit x86 CPUs. That's only the second most common platform to run Linux on.

Also, (void *)0 is a null pointer, even in a stdargs function: as Ian 
pointed out, NULL-the-macro may be defined as '0', which is not a pointer 
in a stdargs context and may have a different bit value.

It took me by surprise that most people here expect NULL to be (void)0. My impression from the
C and C++ standards (which admittedly I haven't looked at recently) is that 0 is the
preferable definition for NULL. Not 0L and not (void)0.

(I know that GCC's headers define it as (void)0. However if it was changed to plain 0, all
correct ANSI C programs should continue to work!)

So, the only clearly correct, portable and even stylistically preferable solution in this case
is ((char*)0). I am surprised that there is discussion about it at all.

I just wonder what exactly will generate a larger discussion here: the development of dpkg
(with the semi-hijack and all) or the merits of NULL pointers.

Indeed, style is an annoying problem.

Sometimes I wish language authors would just define the space and brace layout in the language
spec and make the compiler enforce it. :)

Python made a big mistake in this area by allowing both tabs and spaces.

Just a side note, but Python treats tabs as 8 spaces.

My main point is, I don't understand why we don't have "text" editors advanced enough to
preserve original whitespace style while presenting source code in the user's preferred style.
Given that source code is actually just a big data structure.

I've mentioned the idea of a "structured editor" to a few people before, and they generally
just look at me like I'm insane (which is not unusual), but other times I wonder if we had
more general purpose libraries with something like DOM APIs, would merging and source code
editing not be all the more pleasurable an experience?

Merge conflict -> "aah, statements are semantically identical"
Merge conflict -> "aah, expressions evaluate to the same type"
Merge conflict -> "aah, extra array initialiser added"

etc.

I also appreciate the idea of typing "for" and having a text editor display some sort of
widget that meant you didn't have to type the semicolons, and so on. If it was done nicely it
might greatly reduce the possibility of introducing logic errors due to typos.

In a world where source text is treated like the data structure it is by editing and merging
components, arguments about style largely disappear (although I guess naming schemes will
always come up :).

I find the concept of hand-editing a large data structure in what is basically a glorified hex
editor a little more repulsive than using a GUI to do the same job.

I agree with you.  I'd love to have structured editor, grep, diff and patch tools.

Anything with a well-made definition should be doable, like C's BNF.  Perl need not apply. :)

I would handle the preprocessor by having the editor (and other tools) handle the preprocessed
code and then replacing it with the macro in the display while retaining the macro definition
in the background.  It could be expanded or contracted in the display by a double-click, or
right-click, or a little plus icon.

A lot of your points have merit, but one thing you mentioned is less 
useful than it might at first appear: the `code template' stuff, where you 
type 'for ' and the editor types in (;;) and sticks you after the opening 
bracket. This is problematical for several reasons:

Firstly, the editor is making your cursor jump around without your having 
commanded it to move, and both the point it left and the place it moved to 
is essentially arbitrary (does your editor's template matcher fire after 
space? Bracket? Which section of the for does it move you to? Perhaps it 
moves you to the loop body...)

Secondly, once you're there, there's no way the editor can automatically 
tell that you've finished typing in one section and want to move to the 
next, so you'll have to tell it. Had the template not been there, you 
could have indicated this by pressing the semicolon; but with the template 
in place, you have to hit the right cursor key some number of times, or 
have a right-one-language-token key -- which is still no more convenient 
than hitting ; would have been!

Everyone always uses for loops as an example of where syntactically-aware 
editing would be useful, but to be honest I've never found anything more 
elaborate than autoindenting and automatic closing brace/bracket insertion 
to be any help at all.

Those identifier autocompletion dialogs are even worse, because unless you 
have a hyper-high-end system they make the editor stall for an instant, 
they tend to dump a dialog box up on top of your typing (why not open a 
pane at the bottom of the screen and fill it up?) and they invariably 
don't contain the identifier I'm actually *looking* for anyway. So the 
result is a juddery, flickery, annoying mess, like browing an advert-laden 
site with animation enabled and flash installed. :)

Actually, the Java editor in eclipse has solved this pretty nicely. Type in "for" and hit
Ctrl-Space (their auto-complete trigger). Choose which kind of for loop you want, and it
creates a skeleton. It's even smart enough to look at what arrays are in scope and guess which
one you wanted to iterate over. 

It places your cursor in the first "field", which is the iterator variable name ("i"). If you
modify it, all other references to i are updated to your new name. Hit tab to advance to the
second field, which is the terminating condition. Tab again gets you to the body of the if,
inside the curly braces. 

Or at any point you can bail out by hitting an arrow key or mouse-clicking elsewhere. You're
not locked into just editing those fields. It takes a bit of practice, but is really quite
effective. More so for iterating collections classes and other Java-isms.

I don't really like Java, and eclipse is bloated and has a clumsy UI. But it is a really
powerful tool that manages to make programming faster and less error-prone in many ways. I
miss it when coding in other languages.

The C language standard specifies that the constant 0 in the context of a given pointer type
is taken to mean the null value for that pointer type.

As a result the notion of a universal NULL was brain damage right from the start. The fact
that the K&R book uses the NULL notation is no excuse to tolerate that brain damage in
perpetuity.

As a personal guideline, I consider it cleaner and more correct to just use 0 instead of NULL
or whatever. If nothing else you avoid a conversion from T* to void* and in some contexts that
might involve a runtime cost and/or have other effects.

I prefer this commonly used idiom:

char *p = /* some value */
if (p)      /* p is not the null pointer, just like p!=0, but shorter */
if (!p)     /* p is the null pointer, just like p==0, but shorter */

All style discussions aside, two points:

1) The GPLv2 speaks very clearly on the parties' rights. As a receiver of a GPLv2 licensed
software work, I have the *same* rights to change that work as the original author, so long as
I retain that work's GPLv2 license.

I do not have to ask "permission" of that original author to modify and then distribute his
work in that modified form. What moral rights? Hogwash...

2) When somebody is using "moral arguments" in a technical context its time to *carefully*
analyze their arguments. IMO it usually comes down to this: I don't like what you are doing,
but I have no technical or legal basis for my opinion, so I am invoking my moral rights in
this matter.

PS: IMO they are both wrong on the merits, I'd use 0, and not NULL, nor (char*)0. That is
because the compiler already considers 0 to be the null value for the pointer type "char*".

No casts needed, cruft is cruft, making it harder to grok.

cheers,

"I'd use 0".  Which would be a bug.

We're talking about a varargs function.  The compiler does not know to convert 0 to (char *)0.
This is a bug in many architectures, including the once-popular i386 "compact" and "medium"
memory models.

it seems to be morally right to let the original developerbe in charge, unless he or she is
really obnoxious (but in this case Ian Jackson is the more experienced and the more active
developer and probably more people will agree with him)

Not when he is the laziest producers of commits we have ever seen, no.

If he HAD the support of the majority of the current people working on dpkg, his changes would
have been merged.  But enough of them looked at the tree he wanted to merge as-is and didn't
like what they did see, to move the scale of the power balance towards the current maintainer.

Note that this doesn't mean the *code* is bad, so yes, it is a weird dispute far more over how
the code is delivered to dpkg, than on the actual code being delivered.

And, frankly, I could care LESS who started dpkg more than ten years ago.  IMO, it is critical
infrastructure now, and anyone (the original author and current maintainer included) who
doesn't treat it like that, is not to be let near it.

http://article.gmane.org/gmane.linux.debian.devel.dpkg.ge...

Specifically Guillem Jover, main maintainer of dpkg, writes there (partial quotes):

 ...

The branch has never been in an acceptable state, it needs cleanup,
which Ian has refused to do, repeatedly, and wasted probably more time
and everyone's energy starting this (and previous) massive flamefests
than what would have taken to just fix it.

 ...

Anyway, after the freeze was announced it was clear that Ian was not
going to fix the branch, and because having this feature for lenny is
highly desirable I was just going to have to fix it myself and review
during that process, but got quite sick for a week, during which he
started all this mess.

 ...

Those quotes are misleading without also stating why Guillem considers the feature branch to
be unacceptable. Guillem demands that Ian rebase in order to create a prettified history.
Rebasing is not only an inordinate waste of effort in this situation but will also make it
harder to merge other long-pending work.

"Triggers" is not some kind of experimental hack.  This is a well-written and documented
feature which has been working successfully in Ubuntu for half a year.

It's unfortunate that Guillem was sick for a week, but he blocked the merge for six unsick
months before that.  And as soon as Guillem was once again unsick he started work on more
indenting and renaming of unused parameters.

Debian urgently needs to regain control of this critical package so that experienced
developers can get it back on track.

Read the full message (I quoted only partially) to see why that particular feature branch was
considered unacceptable.

Rebasing certainly does have a cost.  The act of rebasing effectively states that the old line
of development is now dead, and the rebased version is what everyone should be using.

This is not much of a problem if the old line of development was private or no one else ever
merged that work or based new branches off that tip.  But if others have used the old line of
development, they are now obliged to rebase their work too.  In contrast, if you just merge
the branch you get the history as it was developed and all the dependent branches can continue
on as before.

I'm not sure where Ian's branch fits in on this spectrum, but I wouldn't be surprised if the
Ubuntu distro folks have work based on top of Ian's, given that triggers are in that version
of dpkg.

I wonder whether anyone has based their work on Ian Jackson's triggers branch, other than...
Ian Jackson, in his later work.

In fact, currently triggers do not save as much postinst run time as I (and you) would desire.
In most cases, dpkg is run from under apt-get or aptitude. And these apt tools decide by
themselves when to run dpkg with only one package and when run it with a batch of packages at
once (and the bigger is the package list on dpkg command line, the more useful are triggers).
Often when new critical libraries are coming to your system with updates, they are updated
one-by-one, as is decided by apt, so each dpkg run incurs an ldconfig run by itself. The same
is for updating critical components, like udev, mdadm, lvm2, etc. They are often updated
one-by-one as well, which triggers initramfs regeneration on each single dpkg run. So, not
much saving with triggers so far, until package interdependences are reviewed, or until more
batching is allowed by apt-get/aptitude.

Try to understand that renaming unused parameters and indenting are more important to Debian
than functionality that will dramatically speed up installs, help to reduce boot times, and
avoid Debian's own dpkg lagging so far behind Ubuntu as to become a de-facto fork.  If you
successfully pass through this looking glass you'll appreciate the mindset of the famously
non-existent Debian "cabal".

And then you'll understand the kind of mindset that results in Debian's latest beta still
lacking support for popular year-old hardware.  One often has to resort to an unpleasant mix
of Testing and Unstable - a technique well beyond the capabilities of Linux newbies.

There are many excellent Debian Developers but Debian's power-brokers tend to behave like a
high-school prom committee on a bad day.  I guess Debian is no different from other
organisations - the politicians grabbed the power while the professionals were doing the
useful work.

1. The "original" original author of dpkg  was Ian Murdock. Ian Jackson implemented dpkg in
the way it was first released in Debian 1.1.

2. The end of Jackson's active role as maintainer and developer of dpkg ended with the upload
of version 1.4.0 on 12 Sep 1996. This was followed by two years of "non maintainer uploads".
Then Jackson did a "maintainer upload" of version 1.4.1 on 1 Nov 1998. This one included
fairly minor changes.

3. After that the principal developers and maintainers were mainly Wichert Akkerman, Adam
Heath, Scott James Remnant, Frank Lichtenheld, Guillem Jover, Raphael Hertzog, and many
others.

4. There are patches here and there from Ian Jackson since he gave up dpkg development in
1998. The oldest of these is from 2006.

5. So, there where about eight years silence from Ian Jackson regarding dpkg. The program
developed in many ways in this time.

I don't think Ian Jackson can claim dpkg leadership based on this analysis. This would be
similar to the original NCSA HTTPd authors claiming leadership over Apache.

This doesn't mean that the current dpkg maintainers have done everything right.

Then, on to supporting multi-arch (i.e. x86 and x64 packages on the same machine).