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, but should obsolete "ssh-extras <
%version" (or freeze it at "<= 3.6.1p2-4mdk" with the exact same practical
result, since both packages require "openssh = %version")?
7. yp-tools-2.8-1mdk vs. ypserv-2.8-1mdk
Both provide and obsolete yppasswd. I've never set up yp on a recent linux
box. But given that yp-tools contains the yppasswd binary, and ypserv does
not, I'd say that it belongs only to yp-tools. Maybe this is a typo, and
ypserv should provide yppasswdd instead (since it provides the daemon with
that name)?
Solution: ypserv should provide (and obsolete) yppasswdd rather than yppasswd.
8. libalsa-oss0-devel-0.9.0-0.5rc1mdk vs. libalsa2-devel-0.9.2-5mdk
Both provide and obsolete alsa-lib-devel. I suspect problems can easily arise
here, but I can't get libalsa-oss0-devel installed in the first place,
because it seems to drag in all kinds of crazy requirements (the
manifestation is that it asks me to install scribus-i18n-de or
scribus-i18n-fr--see the arts issue below for the reason). I think I know the
solution here, but I haven't been able to test it.
Solution: libalsa-oss0-devel should not provide alsa-lib-devel.
9. gnome-tiles-1-6mdk vs. space-1.0.0-7mdk
Both provide and obsolete gnome-imglib and desktop-backgrounds. But I think
they're both completely independent packages that should be able to exist
separately or together with no problems.
Solution: neither package should obsolete either name.
10. glibc-2.3.2-4mdk vs. uClibc-static-devel-0.9.9-2mdk
glibc obsoletes libc-static, which uClibc-static-devel provides. This may be
correct; I don't use uClibc, so I don't know.
Solution: ??? (may not be a problem?)
11. kernel-* vs. kernel-*
They all provide and obsolete alsa, but I don't think this is a problem, since
you never rpm -U a kernel.
Solution: Not a problem.
12. arts-1.1.2-2mdk vs. kde*-3.1.2-*mdk (and scribus, xdrawchem, komba, etc.)
arts obsoletes just about everything in kde, which may not be a problem,
because you can't install most of kde without arts, and you have to upgrade
them in sync.
But arts also obsoletes packages that aren't directly part of kde--like
scribus and xdrawchem. Basically, anything that provides a name of the form
"kde*3*-*" seems to be obsoleted by arts. If you have any of these packages
installed, they'll be uninstalled when you upgrade kde and arts.
While arts obsoleting core kde packages doesn't have any practical
consequences, and conceptually it seems wrong. Besides, it's harder to guess
which kde packages are core essentials than to just remove all of the extra
obsoletes tags in arts, whether they cause a problem or not.
Solution: arts should not obsolete kde*3*-*.
12.5. scribus-1.0-0.rc1.1mdk, scribus-i18n-de-1.0-0.rc1.1mdk,
scribus-i18n-fr-1.0-0.rc1.1mdk, libscribus0, libscribus0-devel
A side-effect of the arts/scribus problem pointed me toward a completely
separate problem, which may be an isolated issue, or it may be the tip of a
whole new iceberg.
Both scribus-i18n-de and scribus-i18n-fr provide scribus. Meanwhile,
libscribus0 depends on scribus.
So, imagine what happens when you try to upgrade arts through urpmi. Since it
obsoletes kde3-scribus, it tries to uninstall scribus. But then it sees that
libscribus0 depends on scribus. Is there any way to keep that dependency?
Sure, install scribus-i18n-de or scribus-i18n-fr, and you'll have scribus
without that troublesome kde3-scribus.
This is obviously not right.
Solution: scribus-i18n-de and scribus-i18n-fr should not provide scribus.
Maybe libscribus0 shouldn't require scribus (usn't the other way around much
more common?), but I'm not sure about this part.
13. MySQL-4.0.13-2mdk vs. MySQL-Max-4.0.13-2mdk
Both provide and obsolete mysql. Which is fine, because the packages
conflict--in fact, it's desirable to have these packages obsolete each other,
so you can upgrade one over the other.
Solution: perfect as-is.
So, I think that takes care of everything in Cooker as of last Friday.
