July 2008 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] New solver call : resolveQueue
by Stefan Schubert 11 Mar '09

11 Mar '09

Hi, apart from the solver call "resolvePool" ( collect all transactions from the pool, solving this transactions and writing the result back to pool) the solver can work off a given request queue too: /** * Resolve package dependencies: * * The solver works off the given queue and writes back the solution * to pool. * * Returns "true" on success (i.e., if there were no problems that * need user interaction) and "false" if there were problems. In * the latter case, use problems() and later applySolutions() * below. **/ bool resolveQueue (solver::detail::SolverQueueItemList & queue); The queue can have elements which are described in the following classes: base class: SolverQueueItem.h SolverQueueItemDelete.h SolverQueueItemInstall.h SolverQueueItemLock.h SolverQueueItemInstallOneOf.h SolverQueueItemUpdate.h Known problems: - The update and InstallOneOf request does not work correctly. - The error messages are too abstract now for the user. (Jano, you can start implementation now :-) ) Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi(a)suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

6 12

[zypp-devel] package history log file format
by Jan Kupec 04 Aug '08

04 Aug '08

I've got a mail day, so here's another one :O) We need to decide some things regarding the $subject. DATA According to my research, we need to log these data: datetime (e.g. YYYY-MM-DD HH:mm:ss format) action (install | remove | upgrade | downgrade | reinstall) reqby (auto | user) // meaning requested by - user or dependencies pkgname evr arch vendor repo ??? // this is requested, but do we really want it? The vendor // should be sufficient IMO oldevr // relevant for upgrades/downgrades oldarch oldvendor oldrepo ??? comments welcome FORMAT i suggest a CSV format, one entry per line, with values separated by whatever char, e.g. a pipe, example: 2008-10-12 12:55:03|upgrade|user||0.12.0|i386|suse|dvd11|0.11.9|i386|unknown|somerepo 2008-10-12 12:55:10|remove|user|zypper|0.11.9|i386|unknown|dvd11|||| 2008-10-12 12:55:03|install|user|zypper|0.12.0|i386|suse|dvd11|||| This would be machine-readable and still quite human readable. OTHER ISSUES The request is that the package history should be human-readable as well as machine-readable. It could as well be two separate logs, one for humans, one for machines. @Michael (ma): i see you're working on refactoring the zypp commit (?). Please keep in mind that, in case of upgrades/downgrades, we will need also the data of the old solvable from which we upgrade/downgrade there. cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

7 21

[zypp-devel] OS identifier for repositories
by Jan Kupec 31 Jul '08

31 Jul '08

Hi, in order to support repository index services (NU type), we need to introduce a function returning an identifier of the OS. Zypp will use this to filter corresponding repositories from the repo index. Currently we use OSName-arch (e.g. sles-10-x86_64). No problem to get the arch, but how to get the OSName? Do we store this somewhere? As for the interface, i suggest to place the functions to ZConfig: /** autodetected OS Id */ ZConfig::defaultSystemId(); /** OS Id zypp uses */ ZConfig::SystemId(); /** Override the zypp OS Id. */ void setSystemId( const std::string sysname_r, const Arch & arch_r ); /** Reset the zypp OS Id to the default. */ void resetSystemId(); maybe also(?) ZConfig::defaultSystemName(); ZConfig::SystemName(); ... cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 10

[zypp-devel] @Hackers: New policy for libzypp VERSION.cmake!
by Michael Andres 30 Jul '08

30 Jul '08

@ libzypp hackers: In SVN TRUNK we introduced a new tag in the Version.cmake file, that should help us maintaining a correct libzypp version without unnecessary version jumps beween to submissions to autobuild: #======= # SET(LIBZYPP_MAJOR "5") SET(LIBZYPP_COMPATMINOR "4") SET(LIBZYPP_MINOR "4") SET(LIBZYPP_PATCH "0") # # LAST RELEASED: 5.3.0 (2) # (The number in parenthesis is LIBZYPP_COMPATMINOR) #======= - Check and adjust LIBZYPP_PATCH/_MINOR/_COMPATMINOR with respect to LAST RELEASED before any commit to SVN! If LIBZYPP_PATCH was already increased, don't increase it again. If you changed the interface, increase LIBZYPP_MINOR and set LIBZYPP_PATCH to 0, unless someone else did so.... # LAST RELEASED: 5.3.0 (2) The next release should be: 5.3.1 (2) - no interface changes 5.4.0.(2) - binary comatible interface changes 5.4.0 (4) - binary incomatible interface changes - IFF you are going to submitt to autobuild: - Update '# LAST RELEASED: ' un VERSION.cmake to the new (current) version. - Add a line in the changes file telling about the new version. ------------------------------------------------------- I also added a script mkChangelog that might ease maintaining the '# LAST RELEASED: ' tag in VERSION.cmake. You still have to care about: - Check and adjust LIBZYPP_PATCH/_MINOR/_COMPATMINOR with respect to LAST RELEASED before any commit to SVN! Afterwards use mkChangelog to write your changes entry and decide wheter you want to update the release tag. 'mkChangelog -h' will tell you how to use it. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) 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] Patterns from rpm-md repos are ignored?
by Christian Morales Vega 30 Jul '08

30 Jul '08

I don't know too much about patterns, so I don't know if here there is a bug or no. I added the KDE:KDE4:Factory:Desktop repository and found that there exists a /var/cache/zypp/raw/KDE_KDE4_Factory_Desktop/repodata/patterns.xml.gz file with some patterns defined (even if I don't know the format they look like patterns), but "zypper -v pt" only shows patterns from "openSUSE-DVD 11.0", "openSUSE-11.0-Oss", "openSUSE-11.0-Non-Oss" and "openSUSE Education", all of them are using YaST metadata instead of rpm-md. Is this something that just had no time to enter in 11.0 libzypp version, a bug, or I just missunderstood patterns.xml.gz? -- 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] zypper-bindings ignores CMAKE_INSTALL_PREFIX
by Jonas de Buhr 30 Jul '08

30 Jul '08

hallo everyone! i'm building zypp from source (rev 10688) on suse-10.2 Linux RINDERWAHN 2.6.18.8-0.10-default #1 SMP Wed Jun 4 15:46:34 UTC 2008 x86_64 x86_64 x86_64 GNU/Linux with cmake-2.6.0: #cmake --version cmake version 2.6-patch 0 and libzypp-bindings always installs to /usr, na matter what install prefix i set: # rm -rf * # /tmp/cmake-2.6.0-inst/bin/cmake -DCMAKE_INSTALL_PREFIX=/tmp/zypper-inst/usr/ -DSWIG_DIR=/usr/share/swig/1.3.36/ -DCMAKE_MODULE_PATH=/tmp/zypp/libzypp/cmake/modules/ -DZYPP_PREFIX=/tmp/zypper-inst/usr/ /tmp/zypp/libzypp-bindings/ -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking modules in /tmp/zypper-inst/usr/share/cmake/Modules;/tmp/zypp/libzypp-bindings/cmake/modules;/tmp/zypp/libzypp/cmake/modules/ -- SWIG found at /usr/bin/swig -- ZYpp library prefix set to /tmp/zypper-inst/usr/ -- Looking in /tmp/zypper-inst/usr/ -- ZYpp found: includes in /tmp/zypper-inst/usr/include, library in /tmp/zypper-inst/usr/lib64/libzypp.so -- Ruby executable: /usr/bin/ruby -- Ruby vendor arch dir: /usr/lib64/ruby/vendor_ruby/1.8/x86_64-linux -- Ruby include path: /usr/lib64/ruby/1.8/x86_64-linux -- Found PythonInterp: /usr/bin/python2.5 -- Found PythonLibs: /usr/lib64/python2.5/config/libpython2.5.a -- Python executable: /usr/bin/python2.5 -- Python lib path: /usr/lib64/python2.5/site-packages -- Python include path: /usr/include/python2.5 -- Found Perl: /usr/local/arch/bin/perl -- Perl executable: /usr/local/arch/bin/perl -- Perl cpp-flags: -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -- Perl lib path: /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE -- Writing spec file... -- Configuring done -- Generating done -- Build files have been written to: /tmp/build/zypper-build/libzypp-bindings # make && make install (...) Install the project... -- Install configuration: "" -- Installing: /usr/lib64/ruby/vendor_ruby/1.8/x86_64-linux/zypp.so -- Installing: /usr/lib64/python2.5/site-packages/_zypp.so -- Installing: /usr/lib64/python2.5/site-packages/zypp.py -- Installing: /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/zypp.so -- Installing: /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/zypp.pm maybe his is, because it installs into the detected python, perl an ruby paths? /jonas -- // Jonas de Buhr // IVV5 Universitaet Muenster // support(a)math.uni-muenster.de // http://ivv5.uni-muenster.de/ -- 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] Plugin support in libzypp / support
by -x0r- 28 Jul '08

28 Jul '08

Greetings, I would have liked to know if there is already or if there is planned a plugin system for zypper or libzypp ? As plugin system, I mean a simple one, like the one available in apt (calling the plugin and filling it's input with the configuration and what's going on : package updates, installation or removal), or a more complex one, like what yum does with his python plugin system, here, the plugin can interact closely with the package manager. Regards -- 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] Re: [softwaremgmt] Re: zypp-refresh
by Michael Matz 24 Jul '08

24 Jul '08

Hi, On Wed, 23 Jul 2008, Marcus Meissner wrote: > > But this would mean adding another possibility (command argument) to > > the zypp-refresh-wrapper. On the other hand, the updater may be the > > only user of zypp-refresh, so we might as well just change it to > > refresh only the autorefresh-enabled repos and be done with it. > > I would say to only refresh the autorefresh ones, no option. > > (Its what I would expect ;) Agreed. What sense would the autorefresh setting have if it wouldn't affect automatic refreshing. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 6

[zypp-devel] zypp-refresh
by Jan Kupec 23 Jul '08

23 Jul '08

Would anybody care if we change the zypp-refresh utility to refresh only repositories with autorefresh enabled? The issue is that currently it is used in openSUSE Updater Applet and it refreshes _all_ the repos. The question is whether it should only refresh those with 'autorefresh' enabled. https://bugzilla.novell.com/show_bug.cgi?id=410791 I tend to agree that the updater should refresh only autorefresh-enabled repos, but i also think the zypp-refresh should refresh all by default. But this would mean adding another possibility (command argument) to the zypp-refresh-wrapper. On the other hand, the updater may be the only user of zypp-refresh, so we might as well just change it to refresh only the autorefresh-enabled repos and be done with it. cheers, jano -- 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] cmake 2.6
by Duncan Mac-Vicar P. 23 Jul '08

23 Jul '08

We require cmake 2.6 since 11.0 release. Alexander Neundorf details in his blog some of the new things (http://www.kdedevelopers.org/blog/531) -the env. variable CMAKE_PREFIX_PATH, which is used by the FIND_XXX() commands to find installed software (i.e. if you installed kdelibs under the prefix /opt/kdelibs and kdesupport under /opt/kdesupport, set CMAKE_PREFIX_PATH to /opt/kdesupport:/opt/kdelibs and it will be found) -support for cross compiling, let's see if that helps with getting KDE on small devices -defining the "link interface" of libraries, so we can limit the indirect dependencies of libs -much shorter delay between entering "make" and when the first target is built (now a O(N) algorithm instead O(N^2) ) -libraries are linked to with the full path instead of relying on the correct order of the -L and -l flags -a Qt GUI for configuring projects, editing the cache etc. ("cmake-gui") -much faster installation, no relinking needed anymore, the RPATH is now patched directly in the binaries -support for OSX library frameworks, let's see if we want to use that for our libs like kdecore -improved packaging support, including RPM and DEB packages (still quite early, so needs tester) -support for creating Eclipse and Code::Blocks projects -improved documentation, now also for cmake variables and properties, split into separate man pages, and now also supports creating documentation for custom cmake modules (see http://api.kde.org/cmake/modules.html) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0