On Wednesday, November 09, 2011 08:05:31 PM you wrote:
> You can add "%pre" and/or "%post" scripts requiring user-interaction
> to an SRPM's spec file and package/repackage an RPM but it's very much
> frowned upon. You won't get a "nice" debconf dialog but you can
> _PROBABLY_ so the same thing.

The major difference is that an RPM in a system using preupgrade cannot do anything interactive at all, and at one time at least that was enforced by anaconda (stdin, stdout, and stderr redirection enforcement, IIRC).

Unlike an RPM system's upgrade, a Debian upgrade runs in the installed system, with all the tools available to the upgrade scripts that are available in the installed system.  A preupgrade, on the other hand, only downloads the pieces of what is essentially a hard disk copy of a custom upgrade 'DVD' and then reboots to the custom installer, which is the same anaconda that the actual DVD uses to do upgrades.  So the scriptlets in an RPM during the upgrade are running in a special stripped-down chroot with only the bare essentials, and with anaconda in control.

As Nico mentioned, RPM updates are supposed to be unattended.  As Nico also mentioned, upgrades from media (as opposed to using yum update and repo manipulations) do some 'special' processing (orchestrated by anaconda in the upgrade path) to handle certain migrations.  And it must be reiterated: preupgrade just sets up the equivalent of custom *media* for upgrade, and thus the actual upgrades run in the same environment that 'real' media upgrades run in.  

Debian upgrades are for the most part rebootless; I say that because I've done three in the last two weeks due to the way squeeze has to be installed on SGI Altix hardware (in a nutshell: due to the lack of firmware on squeeze install media, you have to install lenny and stepwise upgrade to squeeze, remembering to install the appropriate firmware packages before rebooting with the newer kernel and udev). I've never tried an upgrade from Debian media; I didn't even see that option in the boot up of the lenny IA64 DVD I used to install on the Altix boxen here.

It is a different philosophy, that's for sure, media-based versus installed-system upgrades, with different mechanisms when core libraries are being upgrade underneath their dependents (just for one case). 

But that's drifting all the more off-topic, since SL will likely do what upstream does (and upstream's strategy has historically revolved around media-based upgrades); thus, in order to influence SL's direction in this you'd need to influence upstream first, and the best ways to influence upstream's development are by participating in Fedora and installing/testing the upstream EL betas.  And if you see preupgrade supported you will likely also see media-based version upgrades supported (by upstream and by extension SL) at the same time, since the same code paths are exercised.

Yummed upgrades are a whole 'nother bag of worms, and while I wouldn't mind seeing logs of what Nico has done, it would still be classed as 'unsupported (but working)' by SL, I'm sure.