January 2012 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] Commit plugin for libzypp
by Reshetova, Elena 31 Jan '12

31 Jan '12

Hi, Where can I find more information about the hooks available for libzypp commit plugins? I would like to understand if I can use the plugin to check every package after it has been downloaded, but before it is passed to rpm for installation. I would be very thankful for the information, because this doesn't give enough information. Thank you and Best Regards, Elena.

2 2

[zypp-devel] Issue of libzypp-bindings in opensuse 12.1
by Zhang, Qiang Z 29 Jan '12

29 Jan '12

Hi all, I found some API of python-zypp in opensuse 12.1 are missing. For example: most member functions(edition(), name(),arch(), etc.) of PoolItem are not exist in zypp.py. Could you please help to check? Thanks in advance. Qiang

1 0

[zypp-devel] Problem using zypp.pm in Perl script
by Carl McMullen 27 Jan '12

27 Jan '12

I installed perl-zypp-0.5.3-2.18 on a SLES11-SP1 box this week. I then tried to simply use zypp.pm in a script and get an "undefined symbol:..." error with the 'use zypp; Any thoughts on this? PERL CODE: #!/usr/bin/perl use strict; use warnings; use zypp; RUNTIME ERROR: perl zypp_test.pl Can't load '/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/zypp.so' for module zypp: /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/zypp.so: undefined symbol: _ZN4zypp13Arch_sparc64vE at /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/DynaLoader.pm line 203. at /usr/lib/perl5/vendor_perl/5.10.0/zypp.pm line 10 Compilation failed in require at zypp_test.pl line 6. BEGIN failed--compilation aborted at zypp_test.pl line 6. Thanks, Carl McMullen Build Engineer Cray Inc. St. Paul, MN -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

1 0

[zypp-devel] Depsolver and C API for package management
by Florian Festi 04 Jan '12

04 Jan '12

Hi! We at Red Hat are currently looking for a C based depsolver and C API for package management. In addition we are considering a deeper integration of the depsolver with rpm - both on API and code level. While depsolvers and rpm do different things they are much more similar than the current code bases would suggest. We actually did a prototype implementation in Python of such an integrate design a few years ago [1] (based on a yum-like depsolver). For package management we need a simple API on top of the whole stack that is easy to use. Target audience are tools dealing with packages but not changing the way we deal with packages - like CLI or GUI installers/updaters, system management tools, ... This API needs to hide a lot of complexity and should only offer access to the installed and available packages, allow running simple commands and doing simple adjustments to the configuration (e.g. enable/disable repositories). For plugins and more complicated tools we will probably need another - more complicated - API that is closer to the metal. It would probably allow creating rules for the depsolver and would be dependent of the actual depsolver implementation. This API could be separate and come with lower expectations on stability. So one obvious thing for us to do was looking at libzypp and sat-solver / libsolv. While we have not yet settled to specific solution we already have some ideas and opinions. As there is a chance that you might do something similar and there is the chance to come to a more unified code base in the package management stack we want you to know what we have in mind early. Our conclusions so far: Libsolv is an interesting implementation for a depsolver but does not offer the API we are looking for. It needs some kind of abstraction layer to hide all the moving parts. This is one of the things libzypp does. The libzypp API looks pretty complicated. The "next-gen API for package management?" thread on the zypp-devel (September 2011) did not exactly dispel our concerns about that. As we need a C API using C++ creates a lot of overhead. If libzypp would provide the perfect API just putting a C layer in front would be a good way to go. But doing a lot of simplification within this step (as zpm [2]) will likely require tools needing access to "more internal" parts of the API to either be in C++ or wait for a new C layer being written. This is not a situation we are looking forward to. As we are not as attached to the functionality implemented in libzypp as you might be (we are not using Patches or Patterns) implementing the package management API in pure C is an option we are considering. This layer should also hide libsolv's implementation details from plugins or tools that interfere more deeply with the depsolver than "simple GUI applications". For tools implementing new features it is probably easier to do the implementation within libsolv and then export the new functionality than exporting an API allowing to do so. This kinda breaks the idea of different levels of abstraction but allows keeping the important code paths highly optimized - which is what libsolv obviously aims for. We are also thinking about using libsolv - or at least parts of libsolv for implementing functionality of rpm itself. First tests show that small but notable improvements can be achieved by swapping out data structures - even without replacing the whole mode of operation. We are also considering different approaches of integrating libsolv with the rpm dependency checker but even the basic steps are still undetermined. One possible model would be dropping rpmlib's dependency checker in favor of the sat solver and write some interfacing code. As a result of these considerations we are interested if your discussion about the "next-gen API" has led to further results since September and if you are already in favor of one of the suggested solutions. As the requirements are not fundamentally different for the different distributions there might be a chance of increasing the shared code base and may be even integrating *the* dep solver into RPM if this should prove to be beneficial. Florian [1] http://pyrpm.sourceforge.net/ [2] https://github.com/openSUSE/zpm -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

4 5

[zypp-devel] Does code 11 update repo support scripts like code 10
by Rashmi Ranjan Mohanty 04 Jan '12

04 Jan '12

Hi, The way SLES 10 SP upgrades were happening using the scripts in the in update repositories like *-Online, is it possible to have similar scripts in SLE 11 update repositories ? If its still supported and scripts are present in the repository will zypper and yast run the scripts while doing SP upgrade ? Thanks Rashmi -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

3 2