Up- and downgrading packages (was: Downgrade command ?)

[Andreas Hanke]

Pascal Bleser schrieb:
> It's possible, I did it myself.
> Of course, Xorg is pretty complex case to handle, indeed.
>
> Well, yeah, Xorg is hard to downgrade (but not impossible).

Sorry, for the average user who manages getting his system broken
without knowing in advance ("I've been told that there are updates and
so I had to add the repo just in case" or "I have found the best channel
list on the planet with 30 channels, imported it via smart channel --add
$URL and now my X doesn't start any more"), downgrading Xorg is
literally impossible.

You would have to either

- Move /usr/lib/X11 away manually. Of course in runlevel 3, because it
breaks X.

Or

- Install the old Xorg packages with --excludepath=/usr/lib/X11, so the
offending symlink doesn't get installed. Who reads man packages these
days? And of course, the --excludepath option isn't accessible through
smart, or at least undocumented.

And you would have to undo all the other steps the upgrade did, like
removing obsoleted packages. Just downgrading installed packages doesn't
suffice, because Xorg 7.2 introduced new packages.

And there are file conflicts because of package splits, these are
usually handled for upgrade cases via split provides (currently ignored
by everything except zypp) and "Obsoletes" tags (Impossible to handle
for the downgrade case because you would have to insert "Obsoletes" tags
into the already released, old packages you want to downgrade to).

As an example, assume you have a pinentry package with 3 binaries:

/usr/bin/pinentry
/usr/bin/pinentry-gtk-2
/usr/bin/pinentry-qt

Now you want to cut dependencies by splitting the package. The upgrade
path is not a problem:

Name: pinentry
%files
/usr/bin/pinentry

%package gtk2
Provides: pinentry:/usr/bin/pinentry-gtk-2
%files gtk2
/usr/bin/pinentry-gtk-2

%package qt
Provides: pinentry:/usr/bin/pinentry-qt
%files qt
/usr/bin/pinentry-qt

The upgrade path works because there are no additional files and thanks
to the split provides, zypp knows that if this is an upgrade and the
user previously had a pinentry package installed that provided
/usr/bin/pinentry-gtk-2 and /usr/bin/pinentry-qt, he most likely wants
to get the new sub-packages installed.

But the downgrade case can't work because the old pinentry packages
contains conflicting files, but the depsolver doesn't know because it
does not take filelists into consideration and therefore the downgrade
fails unless the new subpackages are either removed manually or by the
depsolver, but that would require the packager to have known in advance
that the package will later be split this way.

My really general conclusion is that undoing complex packaging changes
is plain impossible in a depsolver because it requires the depsolver to
have more knowledge about the packages than the packager had when he
created the original packages (the ones you want to downgrade to).

Andreas