On Sep 8, 2014, at 1:13 PM, Raphaël Jadot wrote: > Well, it starts to become kinda offtopic now, sorry :) >
Here are the negatives to the libzypp positives: I've been tracking libzypp since inception. > I don't disagree about what you tell about urpmi and the perl hell, libzypp > is fast, well known for its amazing dependancies with multiple sources > management, "vendor change" features, intelligent resolver etc. > Yes libzypp is fast. Meanwhile depsolver performance isn't on any package management critical path. (aside) I'm running rpm5 under yum using callgrind, I can easily generate statistics documenting that old/bad S-L-O-W rpmtsCheck just isn't a critical path bottleneck. What *IS* a critical path bottleneck for depsolvers is attempting a try-and-see approach, with repeated redundant calls that aren't really necessary, and with ancient sanity checks that persist for only hysterical reasons to ensure that the same answer as rpm is achieved. Using SAT, which guarantees an optimal solution, or that no solution exists, is also mostly irrelevant to "real world" distro developers and users. SAT as a boolean assertion checkers is only as good as the metadata on which the assertions are based. Most dependency problems (imho) are typo's and missing data, and SAT simply won't be much help with "missing" or erroneous input data. The better approach (again mho) is better automation, both in generating dependency assertions, as well as in testing that the dependencies actually achieve flawless upgrades. Note that I like libzypp, the code is well written and carefully designed. I just believe that a faster depsolver with more complicated (but manually written into spec files by flawed humans, sigh), isn't the important problem to solve. > The fact is that we need to have the community more involved, and we need > their agreement (also by explaining why and how we will not become a simple > OpenSuse rebrand). > Heh: surely OpenSuSE has at at least as good a brand as OpenMandriva. Don't let your community persuade you otherwise ;-) > My opinion is that we should have significative time to decide. We can't only > rely on the argument that something is too old for replacing it. Many things > need to be taken in account. Will we stick to opensuse development cycle? Or > make a fork? Will we use yast? Adapt a UI? What human resources will it mean > if suddenly the main cooker developers become president of their respective > countries and have no more time for openmandriva? Why not yum, smart...? > Do what Fedora did with DNF+Hawkey: parallel development for 2+ years until everyone was satisfied/comfortable with the change. You won't get a second chance if no user can install/upgrade. > we should make a public page where we put all solutions we know in > competition, with pragmatic pros and cons for each. We should also ask > community to make proposals so we don't miss a good idea by focusing only on > one solution. Then maybe we could invite community to install an OpenSuse > (or other) and test the package manager and give feedback. > The problem with community testing is that you only hear about the flaws after they have been inflicted on end users. That leads to a certain frustration, often anger, and loss of community from others who tire of the politics. hth 73 de Jeff _______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
