» rpm lzma payload and breaking hot upgrade to 11.0

The alpha 3 version of the upcoming openSUSE 11.0 introduced using lzma to compress the package payload (= the actual files in the package) instead of bzip2. This means that packages will be slightly smaller (seems like and will be decompressed faster. Great stuff. Coolo posted some interesting numbers about it, clearly a significant benefit. The only issue with it is that it breaks RPM built without lzma support, in the sense that you cannot install/decompress RPM packages that have their payload compressed with lzma with an RPM runtime (I mean the rpm command and everything that layers on top of it: zypper, yast2, smart, yum, ...) that has been built without lzma support. To clarify: you cannot install RPM packages from openSUSE 11.0 >= alpha 3 on openSUSE < 11.0 alpha 3. While it doesn't sound all that critical for the alpha snapshots, this also means that you cannot do a "hot upgrade" of 10.x to 11.0. With "hot upgrade" I mean an upgrade while the system is running (e.g. using yast2/zypper or smart), as opposed to a "cold upgrade" which is performed by booting from the 11.0 media (CD/DVD) and run the installer in upgrade mode from there. The latter will obviously work and is the only supported+tested method, but nevertheless... I believe there are quite a lot of people who do hot upgrades (e.g. hosted server you don't have physical access to). Now it might be very tricky to solve from a technical point of view. The solution itself isn't all that tough to implement (although not as trivial as it might sound): 10.3's package management solver would have to prioritise the rpm package, upgrading that one first when an upgrade is available, before performing any other upgrade. The problem is rather from an infrastructure point-of-view, as fixing the above mentioned problem (not being to hot-upgrade to 11.0) would mean patching the package solver of 10.3 (and possibly 10.2, as 10.1 is going EOL soon, although people might want to upgrade from the EOL'd 10.1 to 11.0). And patching means releasing new packages -- sounds trivial but it isn't, as it involves QA and a whole lot of a process. So if we can't have it done by code, it has to be done by information. The workaround isn't exactly that complex, one will just have to

rpm --upgrade -vh \ http://download.opensuse.org/.../11.0/.../\ <ARCH>/rpm-4.4.2-<RELEASE>.<ARCH>.rpm

before doing the hot upgrade. The problem, at least in my opinion, lies in communicating that piece of information properly to anyone who will perform a hot upgrade. At the very least, it should be mentioned in the 11.0 release announcements. And I hope that trying to make a little noise around it now will spread sufficiently for people to know about it when 11.0 hits the fans :) What's currently bugging me in the corresponding bug and thread on opensuse-packaging is that it doesn't seem to be important to address it, as "cold upgrade is the only supported method". As explained above, if it isn't reasonably feasible from a technical (or human resources) point-of-view, then fine, that of course should be acceptable to everyone. But resorting to saying it isn't supported isn't all that great... IMHO. I might be wrong though. Is anyone actually using hot upgrade or is the importance of it overweighted in my mind ? On a side note, hot upgrade is something Debian has always been exceptionally good at (arguably, their release cycle is also exceptionally... slow, but that's ok, it's on purpose) and I'm afraid we've always been rather bad at it. It cannot realistically be supported the same way as cold upgrades, but that doesn't mean it has to be made impossible (which isn't the case, see workaround above) or unnecessarily hard in the first place either. And if we want it to improve, we need people to test that scenario when alpha and beta releases are being published and file bugs when needed. Mind you, the last thing I'm saying is that Novell should or must support that upgrade method, but the community could do by specifically testing and filing bugs using hot upgrading. EDIT: Actually, instead of the rpm --upgrade command above, the following would obviously be sufficient (and easier), after changing the list of repositories to 11.0:

zypper in rpm

Which brings us to the following two lines that, in theory, should be sufficient to perform the dist upgrade (after changing the repository URLs to 11.0's):

zypper install rpm zypper dist-upgrade

Note that normally, I'd say that upgrading libzypp and zypper before performing dist-upgrade would be a good idea, but it isn't when coming from 10.3 or below, as 11.0's libzypp is API/ABI incompatible, which means that it's likely to remove quite a few YaST2 modules instead of upgrading those depending packages. And thanks to Jan Claeys to point me to the following python script (and GTK or KDE frontend) used by Ubuntu to perform dist upgrades: update-manager. An interesting approach, and at first sight, a well written piece of software that includes automated tests (in chroot and qemu). No surprise here, it makes sure to upgrade the package management toolchain first (dpkg and apt for Ubuntu -- would be rpm, libzypp, zypper and possibly a few YaST2 modules for openSUSE). But it does include other interesting information (and rules), such as packages to keep at all costs, blacklisted packages, etc...