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@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org