On Friday, I posted a list of provides-obsoletes conflicts in the current
Cooker. And, while there seemed to be lots of interest in the script I wrote
to generate the list, there seems to be much less in the results. But many of
the conflicts that arose need to be fixed.
The symptom is this: If two packages both provide and obsolete the same
virtual package name, then they can only coexist as long as you install both
together, and always upgrade the two together.
If you install one first, then the other, the first gets uninstalled. And if
you have both installed, then try to upgrade just one, the other gets
uninstalled. (If there's are dependencies involved, things get more
complicated--e.g., installing libfnlib0-devel will try to uninstall
libfnlib0, which it requires, so the whole operation will fail--but it never
works out.)
To test this yourself:
1. Take a clean, minimal cooker install (or 9.1, but then you have to go
through the whole rpm/urpmi upgrade, which is a hassle in itself).
2. urpmi gimp gimp1_3. This should work.
3. Remove all gimp packages.
4. urpmi gimp. This should work.
5. urpmi gimp1_3. It works, and now gimp is uninstalled.
6. urpmi gimp. It works, and now gimp1_3 is uninstalled.
For real fun, try this with a whole chain of dependencies (e.g., urpmi ggv).
Or try installing older versions of gimp and gimp1_3 and then upgrading one
or the other vs. upgrading both at the same time.
The three conflicts that triggered this whole discussion (gimp vs. gimp1_3,
libsigc++1.0 vs. libsigc++1.2, and libmysql12 vs. libmysql10) seem to be on
the way to a solution. But there are at least a dozen more that need to be
investigated.
If nobody else is willing to look these over, I'll be happy to do the research
and experimentation and talking with the relevant package maintainers and
come up with fixed specfiles.
But I have the feeling that something this pervasive should probably have the
input of more than a single outsider. Especially because, in a few cases, I'm
not sure I know the right solution.
1. libfnlib0-0.5-3mdk vs. libfnlib0-devel-0.5-3mdk
Both provide and obsolete Fnlib. If you install both together, it's fine--but
if you have libfnlib0 installed, and try to install libfnlib0-devel later, it
tries to uninstall libfnlib0, so the install fails.
Solution: libfnlib0-devel should neither provide nor obsolete Fnlib.
2. xine-lib-compat-plugins-0.9.13-11mdk vs. xine-plugins-1-0.beta12.5mdk
These both provide and obsolete xine-xv, xine-gl, and xine-oss. The result is
that, if you have both installed, upgrading to a new version of xine-plugins
via rpm fails, while upgrading it via urpmi removes xine-lib-compat-plugins
and all codecs that haven't been ported to 1.0 yet (which includes divx4).
Solution: xine-lib-compat-plugins should neither provide nor obsolete xine-xv,
xine-gl, and xine-oss (any package that requires those should be pulling in
the current xine-plugins, right?).
3. apache-conf-2.0.46-2mdk vs. apache2-common-2.0.46-5mdk
apache-conf obsoletes apache-common, which is provided by apache2-common.
Is this right? The whole apache/apache2-coexistence thing gives me headaches;
all I know that it that it works on my installed 9.1 servers, and for that
I'm eternally grateful and amazed
Solution: ??? (may not be a problem)
4. php-cgi-4.3.2-6mdk vs. php-cli-4.3.2-6mdk vs.
apache2-mod_php-2.0.46_4.3.2-3mdk vs. mod_php-4.3.2-1mdk
All four provide and obsolete php430 (there are also conflicts with php and
php3). This seems odd conceptually. And, while they all have to be upgraded
in sync (since they all require an exact version of libphp_common432), if you
have some of these installed and want to add another one, it fails. (For
example, let's say you have a standard server setup, without php-cli, and
decide you want php-cli too. You can't install it.)
Solution: None of these should provide php430 or php3; they can all obsolete
php430 and php3. Those that provide php can continue to do so, but they
should only obsolete "php < %version".
5. linuxdoc-tools-0.9.20-4mdk vs. docbook-utils-0.6.13-3mdk vs.
openjade-1.3.1-16mdk
All three packages provide sgml-tools. The first two also obsolete sgml-tools.
I don't know how these are all supposed to interact, or what the virtual
package name sgml-tools represents (it seems to be required only by
kdevelop). I suspect there's a problem here, but I don't know.
Solution: ??? (may not be a problem?)
6. openssh-askpass-3.6.1p2-4mdk vs. openssh-askpass-gnome-3.6.1p2-4mdk
Both provide and obsolete ssh-extras. While these have to be upgraded in sync
if you have them both, there's a problem if you only have openssh-askpass and
try to add openssh-askpass-gnome. I'm not sure what ssh-extras is supposed to
represent, but it probably belongs in only one of these two packages.
Solution: openssh-askpass-gnome should not provide or obsolete ssh-extras? Or
maybe it should not provide ssh-extras
