Just my experience when testing libzypp based software.
I tried to use the libzypp based software when I installed openSUSE
10.3, but I had a bad experience and returned to Smart and I have been
using it since then. Now trying to test libzypp again I added all the
repositories I have in Smart to libzypp. And tried...
First I refresh all the repositories with "zypper ref" and then I
execute "zypper lu":
~> zypper lu
...
Repository: | Name | Version | Category | Status
-----------------------+--------------------+---------+----------+-------
Main Update Repository | libiniparser-32bit | 4488-0 | optional | Needed
Main Update Repository | openmotif22-libs | 4540-0 | optional | Needed
What? Smart says I have everything up to date. Let's see:
~> rpm -qa | grep -e libiniparser -e openmotif
libiniparser-2.17-25
openmotif-libs-2.3.0-23
Why I "need" an update for a package I don't have installed? I have
libiniparser, but no libiniparser-32bit. And I have openmotif-libs, but
no openmotif22-libs.
And version "4488-0"? Probably something patch related, but it doesn't
says too much to me.
I ignore it and execute "zypper lu -t package". I wants to update a LOT
of packages (remember, Smart says everything is up to date). Let's see
the ones from Education:desktop repository: clucene-core, dosbox, gsl,
inkscape, inkscape-lang, kde4-filesystem, kde4-kalgebra, kde4-kalzium,
kde4-kbruch, kde4-kdialog, kde4-kgeography, kde4-kig, kde4-kpercentage,
kde4-kstars, kde4-kturtle, kde4-l10n-ca, kde4-l10n-es, kde4-marble,
kdebase4-runtime, kdeedu4, kdelibs4, kdelibs4-core, libkde4,
libkdecore4, libkdeedu4, libsndfile, strigi, xfig
OK, true. These are updated versions of installed packages. But I added
the Education:desktop repository because I wanted maxima, scilab and
stellarium from it. I don't want to update the xfig-3.2.5-25 *supported*
package from openSUSE 10.3 for the package xfig-3.2.5-31.2 that probably
is just a rebuild of the same package (so is just a waste of bandwidth)
and that isn't supported. In Smart I set a higher priority to the
official openSUSE repository and so it doesn't tries to update the
packages. With libzypp I could "lock" the unwanted packages, but they
are too much. Priorities help a lot.
OK, forget this one. Let's try the YaST QT software management module.
I have "Autocheck" enabled. I click to install "sabayon" from the main
repository. No complains. I go to "Installation Summary" and see
python-gnome, python-ldap, python-orbit and sabayon-lang also marked to
install like dependencies of sabayon. Now I right click over
python-gnome and click on "Do Not Install"... NOTHING HAPPENS!!! I exit
from "Installation Summary" and return (it should be updated
automatically). Now I don't only have sabayon and his four
dependencies... I also have 29 new dependencies, all of them "-32bit"
packages. Why? Ah, OK, when I say "Do Not Install" it understood "Do No
Install the x86-64 version"... but you can install python-gnome i586
version instead. Well, not what I would expected (Smart says me that to
remove python-gnome I also need to remove sabayon and sabayon-lang, and
asks if I want to do so... looks more logical to me). Now I right click
again over python-gnome and click on "Do Not Install" and a dependency
conflict window appears: "No valid solution found with just resolvables
of best architecture" and "sabayon cannot be installed due to missing
dependencies". Whatever I click or not to resolve the "best
architecture" problem makes no difference... I must solve the "missing
dependencies" problem. But... the proposed solution to the "There are no
installable providers of python-gnome >= 2.18" is to install
python-gnome-2.20.0-3.i586??? There are "installable providers" yes or
no? The solution to not being able to install python-gnome is to install
python-gnome? And if it's proposing the i586 version of python-gnome,
why doesn't proposes the x86-64 one? But I also have the option of
"Cancel" and not resolving the dependency problem at all. If I do so I
end with "Autocheck" enabled but an "Installation Summary" that just
lists sabayon, not his dependencies. OK, no problem, so I just have
sabayon... I click on "Check" and the same dependency conflict window
appears!!! But what is worse, it stills proposes to install the
python-gnome i586 version without giving an option to install the x86-64
version.
Yes, I know, I could selected the x86-64 version of python-gnome, click
on update, and I would have ended again with just sabayon and his four
dependencies. But...
This one was a simple case. I had more complex dependencies cases where
YaST really turns you mad. At the end I returned to Smart. But not
because it's faster or the other typical complains about YaST. I
returned to Smart because with it I always know what I'm doing. I know
what packages will be installed, upgraded, downgraded, removed... and I
know exactly *WHY*. YaST takes decisions I simply don't understand and
it doesn't gives any hint to be able to. When clicking on "Verify
System", why it tries to install 915resolution and smartlink-softmodem
when I don't have a modem and use an nVidia card? And with something
like the OBS repository priorities is a must.
That's from someone that was thinking about returning to libzypp. But
what makes people start using Smart? Install the smart package and open
/usr/share/doc/packages/smart/README.html on your browser. Now read the
sections "Smart Transactions" and "Case Studies". I don't know nothing
about dependency resolution algorithms, but these descriptions make you
think Smart is really good at it. What we know about the libzypp
dependency resolution algorithm? Not so much. From the description from
the Smart README one supposes that libapt, yum, libzypp, urpmi all use a
similar "old" system while smart uses a better one. Perhaps is just
marketing, perhaps is just my bad english, I insist in that I don't know
nothing about dependency resolution algorithms, but that's what one sees
when reading this README.
--
To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org
