dpkg is braindead. Jason, you're wrong.

Jason, you said in your post something that left me thinking:

Proposed solution: make PackageKit do exactly what synaptic has been doing for the past three years: when a package install process blocks on file descriptor 0, unhide a hidden VTE widget. As it stands now, none of the publicly facing Ubuntu or Debian PacketKit pages have proposed any other solution to the problem, and it appears there's no other proposed solution on the mailing list. (Take care to note that this has nothing to do with debconf.)

I absolutely disagree with you.  This goddamned practice of letting packages interrupt the upgrade process willy-nilly on the packager's whim is idiotic and should have dealt with years ago (preferably with death by fire).  Don't tell me that the Debian project had a breakthrough invention when they "invented" the "hey, let's interrupt package installation to ask the user a dpkg-configure question or to run a postinstall script". That is not a breakthrough; it's a practice that should have long been abandoned.

The reason why dpkg has this brain damage is pretty clear: the installation/upgrade process and the post-install configuration process aren't clearly separated. It boils down to a single question: it's fine by me if you want to include a package that needs extra user input for configuration -- so, why don't you ask me for the configuration at first-run time, and ship a package with sane defaults?

The RPM take on this issue has a huge advantage: by limiting user interaction during upgrades/installations, it forces packagers to distribute sanely preconfigured packages. That's the reason you can install Dovecot, Postfix, and SquirrelMail on Fedora, and have a working mail server right out of the box -- save, perhaps, for changing the listening interface setting on the Postfix configuration file.

The Debian way, on the other hand, creates a moral incentive for the packager to punt configuration questions to the user. Honestly, you can't expect end-users to interact with a shell. The minute I show my dad a Synaptic VTE question, is the minute my dad stops using Linux.

This is one of the things that suck big time in dpkg. RPM-based distros don't have this problem. On Fedora, I can make an unattended upgrade and it will work 100% of the time, knowing that the configuration files won't be replaced but I will have a way to diff those configuration files. Not so with Ubuntu. Not so with Debian. I'm being candid here: I've had to answer tens of questions after a Debian dist-upgrade. I've never had to answer a single question after a smart upgrade. Yes, I know I could tell dpkg-configure not to ask me questions, but I wonder when Debian will default to that behavior.

What's more, the RPM way has a fantastic consequence: upgrades are fully transactional. You can't make a transactional upgrade if you're interrupting the upgrade process by opening stdin to ask bullshit questions or other hackery. Honest, the need to run apt-get -f install bullshit is something I've never, ever in my life experienced with Fedora's or Red Hat's RPM. And it's a weekly fucking occurrence in Ubuntu!

Just now, I had temporarily turned Nagios2 off with /etc/init.d/nagios2 stop, and the goddamned apt-get -f install won't finish because it insists on dpkg-configuring Nagios2, and the dpkg-configure process fails because it attempts to shut down Nagios2 and that fails, leaving my system in a circle-jerk of partial configuredness, that I wouldn't know how to fix if I didn't have ten years of Linux experience.

Oh, and for the record, the other reasons are:

1. You can't have two versions of the package with the same name installed in the system (I have visited this argument before). Not very used in the RPM world either, but I have put that use into practice.
2. You can't do an rpm -Va, and have dpkg check for permissions, dates, times, and file sizes/sums. What the hell were the dpkg developers thinking? This is practically the first thing I use to audit a server right before I take it under my wing, just to get a clear idea of what the people before me did with it.
3. When you remove a package with dpkg, the configuration files remain unless you purge it. Why can't dpkg do like RPM -- erasing configuration files unless they were modified by the user? Two different remove operations are one too many.
4. dpkg happily lets you destroy your system.

And, quoting you:

This has the added benefit of making it possible for any user on any distro. to unhide the VTE window when something goes wrong--and we all know that something goes wrong with package managers all the time.

I dunno about your experiences with Red Hat or Fedora, but when I use a GUI package manager on Fedora, and something goes wrong, what I'm interested in is the output of stderr. All GUI package managers neatly show these messages nowadays. And I rarely see any error dialog box with stderr contents. So don't start with the "something goes wrong with package managers all the time" bullshit.

So, let's amend your last paragraph: let's make PackageKit redirect /dev/null into the dpkg subprocess. That should take care of things neatly, and screw all braindead packages out there. What's more, if the package somehow refuses to continue installing, let's send dpkg a SIGKILL after a while, then prompt the user to change to a non-braindead distribution. So PackageKit doesn't support your favorite brain damaged behavior? Sucks to be you.

Jeez, how much more of this obsolescent crap and stupid policy do we have to swallow, just because it's the policy of the most widely used distro? I thought open source and free software were about meritocracy, not the tyranny of the majority. And I wish that the portion of the brain of the developer that conceived this "installation is interruptible" brain damage would just necrotize thanks to an aneurysm.