September 2011 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] {libzypp-10.x} Replacing libsatsolver by libsolv (seriously!)...
by Michael Andres 26 Sep '11

26 Sep '11

JFYI: In the near future for libzypp-10.x developers: - We'll move away from libsatsolver and start using libsolv (https://github.com/openSUSE/libsolv) Recent package is available in obs://zypp:Head. - We will also start using some of the new C++11 features, so as developer be prepared and have a recent (4.6) compiler installed. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma(a)suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 5

[zypp-devel] libzypp and C++11
by Duncan Mac-Vicar P. 26 Sep '11

26 Sep '11

Now that C++11 is final, I would like to bring the discussion of using some features in future libzypp that could simplify parts of the code. gcc 4.6 will be already included in SLE-11-SP2, so if we use C++11 features on ZYpp 10.x (Factory) and in the future SLE-11-SP3 takes ZYpp 10.x or 11.x, it should not be a problem. Some of the features that look interesting for ZYpp: Type inference (auto keyword): to get rid of iterator boilerplate lambda expressions: defining callbacks inline for stuff like progress, keyring, etc nullptr: strongly-typed null std::initializer_list<> Uniform Initialization Range-based for-loop (kill our for_ :-) ) .... -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] is this a bug in libzypp?
by Dave Plater 23 Sep '11

23 Sep '11

I'm busy debugging the lilypond build in home:plater:lilypond and this involves adding various packages to the sub project to try to get the same build results in 11.3, 11.4 and factory repos. To avoid network noise I use an unattended cron job to do a zypper dup of KDF and the above mentioned repo to my x86_64 11.4 system. A test "zypper -v dup -r plalily" today has alarmed me as it wanted to install all the i586 ghostscript rpms from the ghostscript-library package. I went through /etc/zypp/zypp.conf and couldn't find any option to prevent this from happening. There is something wrong with the repo as even after deleting the i586 binaries from 11.4 the i586 directory still has ghostscript but x86_64 has nothing, this is not a libzypp problem the problem is that if this happens in KDE:Distro:Factory for instance I'll end up with a whole bunch of i586 rpms installed. Why is libzypp allowed to change x86_64 packages to i586 silently? I understand the reasoning behind having i586 packages that have never had x86_64 versions and are supported by 32 bit x86_64 libs but allowing an i586 package to replace an x86_64 one without asking has no logic in it at all and there should be a mechanism in place to allow a user to prevent this. Thanks Dave P -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 3

[zypp-devel] Re: next-gen API for package management?
by Duncan Mac-Vicar P. 21 Sep '11

21 Sep '11

On 08/31/2011 09:50 PM, Pascal Bleser wrote: > Without the bindings, nobody will use it, and we will never know > what funny and interesting ideas people might end up with. I am more interested into the simple API design than the bindings, but I do believe that once the first is accomplished, the second comes very naturally. Mostly because we have duplicated code between zypper, PK and YaST in order to do this set of "useful" operations. The hardest part IMHO is choosing the granularity z.install("foo") is reading the list of repos, refreshing them, selecting some packages to be installed, and committing. Also, you mention z.what_provides(:capability => "smtp_daemon").each { |p| puts "#{p.name} #{p.version} #{p.repo.name}" } So you are getting an object, but then you install by string. I guess the trick here is to offer them both, and then overload them in the script language as if they where one: C mylib_install_by_capability("apache") mylib_install_solvable(obj) ruby Mylib.install(obj) -> obj.is_a?(Solvable) ? install_solvable(obj) : install_by_capability(obj.to_s) Another tricky part to get right is callbacks :-) -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 19

[zypp-devel] Replacing satsolver(C) by libriss(C++)
by Michael Andres 21 Sep '11

21 Sep '11

Just kidding, but .... http://gitorious.org/riss -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma(a)suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 4

[zypp-devel] new branch created: SuSE-SLE-11-SP2-Branch
by Michael Andres 20 Sep '11

20 Sep '11

Hi. I just created the SuSE-SLE-11-SP2-Branch for sat-solver libzypp zypper zypp-dialogsolver zypp-solver-testcase-runner libzypp-bindings at git@github.com:openSUSE. libzypp 9.x will be continued in this branch. Jenkins tests and submitts SuSE-SLE-11-SP2-Branch packages to obs://zypp:SLE-11-SP2-Branch. Master is now open for factory development (libzypp 10.x). -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma(a)suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] libzypp-bindings: callbacks support Python
by Zhang, Qiang Z 13 Sep '11

13 Sep '11

Hi Klaus and all, Does callbacks works for python in libzypp-bindings? I have just used the test code(swig/python/tests/commit_callbacks.py), but it seems don't work and CommitReceiver have never been called. Do you know what's the root cause? Thanks In advance. Qiang

2 13

[zypp-devel] Unable to install ARM packages.
by Marko Saukko 07 Sep '11

07 Sep '11

Hi, In MeeGo 1.3 we are having a lot of problems with ARM architecture where are are not able to install packages. Output to the terminal when "zypper install nano" is called: http://pastie.org/2491766 /var/log/zypper.log file: http://pastie.org/2491761 Any suggestions? libzypp has already the linker.patch that adds the "list( REVERSE zypp_lib_SRCS )" line to zypp/CMakeLists.txt. Regards, Marko -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 5

[zypp-devel] libzypp-bindings: More API support
by Zhang, Qiang Z 02 Sep '11

02 Sep '11

Hi all, We would like to use more python API in libzypp-bindings, such as PoolQuery, and I have tried to import the related API to libzypp, but fails. Here's the patch I used to import PoolQuery API: --- diff -uNr libzypp-bindings-0.5.8/swig/PoolQuery.i libzypp-bindings-0.5.8.new/swig/PoolQuery.i --- libzypp-bindings-0.5.8/swig/PoolQuery.i 1970-01-01 08:00:00.000000000 +0800 +++ libzypp-bindings-0.5.8.new/swig/PoolQuery.i 2011-08-30 13:19:41.067491333 +0800 @@ -0,0 +1 @@ +%include <zypp/PoolQuery.h> diff -uNr libzypp-bindings-0.5.8/swig/zypp.i libzypp-bindings-0.5.8.new/swig/zypp.i --- libzypp-bindings-0.5.8/swig/zypp.i 2011-08-30 13:18:41.251366083 +0800 +++ libzypp-bindings-0.5.8.new/swig/zypp.i 2011-08-30 13:48:54.900428645 +0800 @@ -59,6 +59,7 @@ #include "zypp/Resolver.h" #include "zypp/pool/GetResolvablesToInsDel.h" +#include "zypp/PoolQuery.h" #include "zypp/Product.h" using namespace boost; @@ -159,6 +160,7 @@ %include "TmpPath.i" %include "Resolver.i" %include "ZConfig.i" +%include "PoolQuery.i" %ignore zypp::ZYpp::setTextLocale; %ignore zypp::ZYpp::getTextLocale; --- But, I have got the following build error. ########### /home/abuild/rpmbuild/BUILD/libzypp-bindings-0.5.8/swig/python/libzypp_python.cc: In function 'PyObject* _wrap___lshift__(PyObject*, PyObject*)': /home/abuild/rpmbuild/BUILD/libzypp-bindings-0.5.8/swig/python/libzypp_python.cc:122672: error: redefinition of 'PyObject* _wrap___lshift__(PyObject*, PyObject*)' /home/abuild/rpmbuild/BUILD/libzypp-bindings-0.5.8/swig/python/libzypp_python.cc:107956: error: 'PyObject* _wrap___lshift__(PyObject*, PyObject*)' previously defined here /home/abuild/rpmbuild/BUILD/libzypp-bindings-0.5.8/swig/python/libzypp_python.cc: In function 'PyObject* _wrap_dumpOn(PyObject*, PyObject*)': /home/abuild/rpmbuild/BUILD/libzypp-bindings-0.5.8/swig/python/libzypp_python.cc:122718: error: redefinition of 'PyObject* _wrap_dumpOn(PyObject*, PyObject*)' /home/abuild/rpmbuild/BUILD/libzypp-bindings-0.5.8/swig/python/libzypp_python.cc:122336: error: 'PyObject* _wrap_dumpOn(PyObject*, PyObject*)' previously defined here /home/abuild/rpmbuild/BUILD/libzypp-bindings-0.5.8/swig/python/libzypp_python.cc: In function 'PyObject* _wrap_ZYppFactoryException_locker_pid(PyObject*, PyObject*)': /home/abuild/rpmbuild/BUILD/libzypp-bindings-0.5.8/swig/python/libzypp_python.cc:123604: warning: 'pid_t zypp::ZYppFactoryException::locker_pid() const' is deprecated (declared at /usr/include/zypp/ZYppFactory.h:33) ########### Do you have any comments? Thanks In advance. Qiang

4 4

[zypp-devel] next-gen API for package management?
by Duncan Mac-Vicar P. 01 Sep '11

01 Sep '11

ZYpp API is a toolkit. It provides not only the package management API but all the classes and components like a LEGO set. In this regard, its goals as an API are very similar to LLVM. This makes the API complex to wrap in scripting languages, both technically and from the user point of view: the wrapped API does not make much sense for simple tasks. However, we have seen the need for a simple client API that encapsulates all the knowledge there. Ideally this would be a simple API, comparable to what zypper offers, or what PackageKit offers. This API could actually be used by zypper and the PackageKit backend, which would serve as a good testbed for its usefulness. The API could be done in plain C, exposing only opaque structs keeping the ZYpp data and some API to do operations, but avoiding exposing other types that would conflict with scripting languages own stdlibs (Pathname, Date, etc), so restricting itself to basic types only. Having a simple C API would allow for easy binding: you can use swig, ffi, interpreter own API, etc. If we follow conventions like class_methodname(class *, args).. etc bindings get easier... Now, how this API would look like? Lets collect use cases. Where possible I would prefer actual client code examples in C, python, etc together with the use case (only usecases could lead to a committee-taste API). -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2