June 2007 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] Extending pattern definition
by Jiri Srain 09 Jul '07

09 Jul '07

Hi! In order to allow workflows bound to patterns we need to extend the pattern definition on the media as well as the database and in-memory representation of a pattern. We need following tags: "workflow_file" : string // file describing the workflow on the media "workflow_file_checksum" : the same as other checksums "workflow_order" : string // to allow ordering, string for better extendibility (the names can be adapted to fit attribute naming schema) The suggestions for the SuSEtags metadata format are =Wkf =WkfCSum (if not specified in content file) =WkfOrd ZYPP is not required to process this data anyhow (maybe except the checksum?), all that's needed is to deliver the data to YaST. The update of package bindings will be trivial. The document is (inside Novell network) available at http://users.suse.cz/~locilka/PatternsAndAddOnsWithWorkflows/proposal-2007-… Duncan, Jano, is it possible to get this implemented for 10.3? -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

5 18

[zypp-devel] use case question: repository setup rpm.
by Michael E Brown 02 Jul '07

02 Jul '07

I have some questions regarding repository setup for zypp. I know the "zypper service-add ..." stuff, and I currently have the Dell public repositories bootstrap script use this in the script. I was looking to improve this, though. For yum setup, the setup is simply this: drop a "dell.repo" file in /etc/yum.repos.d/. This is quite nice for the simple reason that it is something that RPM manages to do exceedingly well. I have a "dell-unsupported-repository-1-1.noarch.rpm" that I use for this purpose. The other nice thing about this is that I can very easily manage the transition from config to config. For example, if I make a change to the repository layout, I can release updated repository RPMs with the new configs. As I normally will make the old and new layouts compatible, I can simply wait a period of time before removing the backwards compatibility (either symlinks or http redirects, etc). This makes things nice and easy to manage from my side. For zypper, I dont see a nice way to update the client's configs easily via RPM. I tried to do the "zypper service-add ..." inside the RPM %post, but all I managed to do was hang zypper when the RPM was updated as part of a zypper upgrade. What is a good way to handle this situation? Is there something that can be added to the next version to address this? Note: All my testing was carried on on SLES10 and SLES10 SP1. Thanks, Michael Brown Maintainer, Dell unofficial yum repos Dell, Inc -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2

[zypp-devel] [RFC] QueryBuilder and (Resolvable)Query
by Jan Kupec 30 Jun '07

30 Jun '07

Hi! Here is my proposal of a new libzypp API for various metadata queries. It should be useful for YaST package managers, zypper, YaST online update and maybe others. Pease see attached QueryBuilder.h file and comment on the design and usability. QueryBuilder is meant to build an sqlite query for libzypp's metadata cache database and to be used by ResolvableQuery::query(QueryBuilder,ProcessingFunctor) function (or other Query class) to do complex resolvable data queries. Result of these queries will be processed by ProcessingFunctor (read on). The reason to create such an API is to have a convenient API for coding various kinds of user queries, so that apps using libzypp don't have to code the functionality by themselves by traversing the resolvable pool. And since we (will hopefully) have the new metadata cache database, there is another reason: to make use of the database to speed up the search and save memory requirements (don't load the pool, just query the database). I would have to code it once in zypper anyway, so this way it can be reused by others as well. CODE EXAMPLE: //////// code START ///////////////////////////////////////// bool is_regexp; // treat the search string as regexp? bool search_summaries; // search also in summaries? string search_string; // user given search string Resolvable::Kind kind; // the result will be limited to this kind <snip> zypp::cache::QueryBuilder builder; builder.addName(search_string, is_regexp); if (search_summaries) builder.addAttribute(zypp::cache::attrResObjectSummary(), search_string, is_regexp); builder.addKind(kind); zypp::cache::ResolvableQuery resquery; resquery.query(builder, processing_functor); //////// code END ///////////////////////////////////////// (the functor is function<bool( const data::RecordId &, data::ResObject_Ptr )> we can provide one which would use Selectables (or NameKindProxy) for yast as well) FEATURES - search by name, any cache attribute, kind, (future: installed status), version - uses simple strings or regexes - search by dependencies (select resolvables which are required by e.g. pattern X) - use multiple search conditions and choose to require all or any of them satisfied. IMPLEMENTATION - based on given arguments and options, an sqlite command will be built This command will be executed by a ResolvableQuery::query() or another Query class (see attachment - just a stub). - i decided to write field values into the sqlite command string itself. Using variable names and bind values to them would be too complex. - regexes - sqlite's REGEXP keyword will be used, bound to user (libzypp) defined regexp matching function of our liking. ISSUES - what regexp syntax do we want to support? - something missing/to be changed in the API? Cheers, Jano

2 1

[zypp-devel] Re: [yast-devel] Adding missing API to libzypp (or between libzypp and apps)
by Michael Andres 29 Jun '07

29 Jun '07

On Wed, Jun 27, Katarina Machalkova wrote: > > I don't have any feature request for libzypp; we can work out things > > pretty easily (say, dependencies listing), and I think it already has > > enough bloat. :P > > Well, the idea steadily evolved into something like 'writing a wrapper over > libzypp' (called 'zypp4ui' for the time being) so that an application that Not wrap - fix, improve and cleanup zypp. > needs to call libzypp function doesn't have to use libzypp low-level > functions. What is a 'libzypp low-level function'? > Example: in your application, instead of doing: > > list <ZyppSelectable> patchList; > for ( ZyppPoolIterator it = zyppPatchesBegin(); it != zyppPatchesEnd(); > ++it ) > { > ZyppSel selectable = *it; > ZyppPatch zyppPatch = tryCastToZyppPatch( selectable->theObj() ); > > if ( zyppPatch ) > { > patchList.push_back (*it) > } > } > do_something_with_all_patches( patchList ); > //example_end > > one just does: > > list <ZyppSelectable> patchList = zypp4ui::Patch::listAll(); > do_something_with_all_patches(patchList); > > This low-level iteration through zypp pool would be wrapped into > zypp4ui::Patch::listAll(), so that your application just calls this function, > without adding the iteration code itself into the code of your library. The larger the ammount of objects you process, the worse it is to build a temporary conatiner just to process these items. Avoiding them and becoming more flexible is one idea behind the concept of using iterators, algorithms and functors. We have basic support for this. It for shure needs polishing before Huha happily uses it. ;) The Selectable IMO has a big drawback: It's the UIs request to have one Selectable for each installed item. While the Pool contains all individual items (packages, patterns,...), the Selectable groups them by name and kind. A Selectable(package,kernel) contians a link to one installed and all available kernel packages. This is fine as long as there are 0 or 1 kernel packages installed. Each kernel package known by the Pool is 'conected' to the same Selectable. Pool Selectables i:kernel-1.0 ---+ | a:kernel-1.2 ---+---- S(package,kernel) a:kernel-2.0 ---+ Unfortunately we support installing multiple versions in parallel. So if there are 2 kernel packages installed, we have 2 Selectables for (package,kernel). Each one connected to all available, but a different installed version. Pool Selectables i:kernel-1.0 ---+---- S1(package,kernel) ----+ | i:kernel-1.2 ---+---- S2(package,kernel) --+ | | | a:kernel-1.2 ---+--------------------------+-+ a:kernel-2.0 ---+ This missing one-to-one relation is basically the reason why Selectables were not integated into the Pool. A Selectable is not that helpfull because it does not neccessarily link to ALL (package,kernel) items in the Pool. It lacks information that might be required to make decisions. And vice versa a Pool item as result of some query does not necessary lead to only one Selectable. Pool NameKindProxy i:kernel-1.0 ---+ i:kernel-1.2 ---+ +---- NKP(package,kernel) a:kernel-1.2 ---+ a:kernel-2.0 ---+ NameKindProxy does, what Selectables IMO should do, it links to all known Pool items of certain name and kind. And each Pool items is connected to one NameKindProxy. An object like this can easily be kept and maintained in the Pool. Pool items can contain a backlink to the corresponding NameKindProxy It would be a good place to provide convenient status manipulating methods. It could use the same policies as the solver to e.g propose the 'best' package for install or upgrade. Everything you improve here, will be available to all zypp based applications (zypper, pkg-bindings,..), and not just for the YaST UI. The UI Selectable would be a good candidate, IF it could avoid the duplicate Selectables. -- 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] JFYI ADDED: Pathname::asUrl() /* Url representation using dir schema. */
by Michael Andres 26 Jun '07

26 Jun '07

(In REFACTORING-10_3) So you can avoid constructs like Url( std::string("dir://") + path.asString() ) (or even worse), but simply write path.asUrl() -- 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] Adding missing API to libzypp (or between libzypp and apps)
by Jan Kupec 25 Jun '07

25 Jun '07

Hi there! Check out this idea page and see what's needed and who intends to do what: http://idea.opensuse.org/content/ideas/better-api-for-applications-using-li… This idea might be of interest for people writing applications using libzypp who were missing some functionalities and libzypp devels. In particular: YaST package manager UI (qt, gtk, curses), zypper, YaST online update. If you have any comments or want to participate, edit that page and use the discussion facility there and describe what would you like to do. 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] status 22.6.
by Jan Kupec 25 Jun '07

25 Jun '07

- dropped last pieces of old zypp code from zypper - enabled the rest of commands - service-rename, sr (renamerepo, rr) command reimplemented The basic work on zypper related to zypp2 is essentially finished. What's next is to take advantage of the sqlite database to enhance performance of zypper, mainly zypper search, but also others. But this can be part of general zypper development. 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] Solver is more verbose
by Stefan Schubert 22 Jun '07

22 Jun '07

Hi, i have added these new API call in order to show the user more information about why and who has selected a resolvable: /** * Gives information about WHO has selected an item for installation. * * \param item Evaluate additional information for this resolvable. * \return A list of structures which contains: * item Item which has triggered the selection of the given param item. * cap Capability which has triggerd this selection * capKind Kind of that capability (e.g. Dep::REQUIRES,Dep::RECOMMENDS,... ) * * Note: Start a solver run before in order to have a result. Not matter if it is valid or invalid. * */ const solver::detail::ItemCapKindList isSelectedBy (const PoolItem_Ref item); /** * Gives information about WHICH additional items have been selected by the given item. * * \param item Evaluate additional information for this resolvable. * \return A list of structures which contains: * item Item which has BEEN triggered by the selection of the given param item. * cap Capability which has BEEN triggerd by this selection * capKind Kind of that capability (e.g. Dep::REQUIRES,Dep::RECOMMENDS,... ) * * Note: Start a solver run before in order to have a result. Not matter if it is valid or invalid. * */ const solver::detail::ItemCapKindList selects (const PoolItem_Ref item); 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

1 0

[zypp-devel] zypper going it's own way
by Jan Kupec 22 Jun '07

22 Jun '07

Hi, i would like to drop rugs concepts from zypper and use zypp concepts instead. Concepts like /catalog/ or /service/ are not (to be) used in zypp(er). (I hope the current 'installation source vs. repository' flame-war on yast-devel will not affect this badly and that the terminology will be agreed upon shortly.) In fact, i already defined new command aliases in zypper-command [1] and started to update rug-zypper compatibility list [2]. e.g.: ------------------+----+----------------------+---------------------------- zypper command | St | rug command | rug description ------------------+----+----------------------+---------------------------- addrepo ++ service-add (sa) Add a service rmrepo ++ service-delete (sd) Delete a service listrepos (lr) ++ service-list (sl) List the available s... I'd like them short and have shorthands for those which can't be short (like in rug). Also, i'd like zypper to use --repository, -r instead of --catalog, -c to specify repository to work with. (or do you want `s/repository/installation source` and `s/repo/source`?). Of course *rug compatibility will be preserved* (and improved). But man page and help text should mention the new zypper commands and mention rug commands in compatibility notes/tables/etc. This will NOT affect zypper's functionality or future features. It's just an attempt to clean up the confusing terminology for good. the links: [1] http://svn.opensuse.org/svn/zypp/trunk/zypper/src/zypper-command.h http://svn.opensuse.org/svn/zypp/trunk/zypper/src/zypper-command.cc (see ZypperCommand::parse(const std::string & strval_r) method for the definition of the aliases) [2] http://svn.opensuse.org/svn/zypp/trunk/zypper/doc/zypper-rug Your opinions? Cheers, Jano -- 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] Source refresh policy
by Jiri Srain 21 Jun '07

21 Jun '07

Hi! This is my suggestion on how to define the refresh policy with refactored ZYPP: We need to keep the information when last a source was refreshed in order to decide whether a source needs to be refreshed or not. In addition, we will need some policies defining whether a source should be refreshed or not. The basic refresh should be done by a cron job. However, there may be a reason not to do refresh via a cron job and do it only when SW management tool starts. There are two kinds of tools: 1. Tools which take care of having the system up-to-date. They must always work on as fresh metadata as possible 2. Tools which should install a package. They should work as fast as possible. we can pay the price of installing package which already has an update at least in some cases. Therefore we need two different policies depending on the kind of source (this is optional) and on the operation user performs (they can be set to vehave the same of course). How often refresh is being performed via cron (if it is) can be read from the cron configuration, I don't think we need to put this information to any configuration file. In addition to cron, I suggest adding following variables (comments hopefully explain their meaning) --- snip --- # should the on-line update paplication (eg. YOU) consider doing a refresh # or should it rely on a cron job? ONLINE_UPDATE_AUTO_REFRESH="yes" # if the time since last refresh is higher than specified amount of time, # the update tools refresh the source first # if it is an update source (provided we have the tags); 0 means to refresh # always when starting the on-line update tool # filtering on-line update sources is questionable (consistency) ONLINE_UPDATE_REFRESH_INTERVAL="1h" # should the desktop applet perform any refresh or just rely on cron job? DESKTOP_APPLET_REFRESH="yes" # define how often the desktop applet should perform refresh. DESKTOP_APPLET_REFRESH_INTERVAL="3h" # master switch for enabling or disabling auto refresh for software # management tools (eg. 'yast -i', 'zypper') # if disabled, refresh must be performed manually or via cron INSTALLER_AUTO_REFRESH="yes" # auto refresh interval for tools primarily installing packages, not doing # update; "0" means always when initializing source(s) INSTALLER_AUTO_REFRESH_INTERVAL="24h" --- snap --- The above variables can be added to /etc/sysconfig/sw_management. The way time is specified can be discussed, I guess that the granularity of hours or at most minutes is perfectly sufficient, however, we may support any of fixed units or specifying the units with the value (as in examples above). Any other ideas or suggestions? -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

6 10

[zypp-devel] REFACTORING-10_3: Revision 5818: everything compiles....DOES NOT COMPILE!
by Michael Andres 21 Jun '07

21 Jun '07

Please update to gcc-4.2. -- 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] Re: [zypp-commit] r5810 - /branches/REFACTORING-10_3/
by Duncan Mac-Vicar 21 Jun '07

21 Jun '07

On Wednesday 20 June 2007 13:54, mlandres(a)svn.opensuse.org wrote: > Author: mlandres > Date: Wed Jun 20 13:54:56 2007 > New Revision: 5810 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=5810&view=rev > Log: > Temporary branch to switch to the new zypp API. > > Added: > branches/REFACTORING-10_3/ > - copied from r5809, trunk/ However trunk has already some new changes. Arvin fixed some typos. mvidner has a commit too. That was my point when I said, lets freeze trunk on a tag/branch, and people continue working on trunk. What is the policy for the testsuite? Do we need to branch it? -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

4 3

[zypp-devel] Please watch gcc warnings..
by Michael Andres 21 Jun '07

21 Jun '07

No, it is not sufficient, that the code compiles. One benefit of cmake are easy to spot gcc warnings. So don't slack off and fix them, if you see them. warning: return type defaults to 'int' warning: no return statement in function returning non-void warning: control reaches end of non-void function warning: dereferencing type-punned pointer will break strict-aliasing rules gcc42 in stable --------------- I just installed the packages from /dist/install/stable-x86/ on my 10.2 without problems. Except for the fact, that zypp does not compile. Going to fix it. As there is some code that passes gcc41 but is rejected by gcc42, all developers should migrate ASAP. -- 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

2 3

[zypp-devel] repo modification use cases
by Jan Kupec 21 Jun '07

21 Jun '07

- rename repository (alias, i.e. identifier) (if it is the only repo in the .repo file, rename also the repo file) - disable/enable the repo - disable/enable autorefresh for the repo - set long name (description) - disable/enable gpg check, specify signature location - add/remove a baseUrl - add/remove a mirror URL - ...anything else? - since we support more repositories defined within a single .repo file this will need to be considered if we decide to implement the modifications by removing old repo file and replacing it with a new (modified) one. I think an additional API would be handy for this task (covering all of the above) at last. Something like: RepoManager::modifyRepository(const std::string & repo_alias, const RepoInfo & new); Client just creates it's own modified RepoInfo object and leaves all what's needed on zypp. Of course we need to provide methods for modifying the RepoInfo that we currently don't provide (if any). Also RepoManager::getRepoInfo(const std::string & repo_alias) would be nice so that clients don't need to extract the RepoInfo file from knownRepositories() themselves, if they want to create modified RepoInfo out of the original one. This would be a very simple convenience method. So the client code could look like: RepoManager manager; RepoInfo repo = manager.getRepoInfo(alias); repo.setAlias(new_alias); repo.setEnabled(false); repo.removeMirror(url); // whatever manager.modifyRepository(alias, repo); Cheers, Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2

[zypp-devel] Some numbers of the ported zypper
by Duncan Mac-Vicar Prett 20 Jun '07

20 Jun '07

dmacvicar@piscola:/space/build/zypp/trunk/zypper> time sudo src/zypper sl # | Enabled | Refresh | Type | Name | URI --+---------+---------+--------+----------------+------------------------------------------------------------------------ 1 | No | No | rpm-md | filesharing | http://software.opensuse.org/download/filesharing/SUSE_Factory/ 1 | Yes | No | rpm-md | home:dmacvicar | http://software.opensuse.org/download/home:/dmacvicar/openSUSE_Factory/ 1 | Yes | No | rpm-md | ruby | http://software.opensuse.org/download/ruby/openSUSE_Factory/ real 0m0.034s user 0m0.028s sys 0m0.008s dmacvicar@piscola:/space/build/zypp/trunk/zypper> time sudo src/zypper -v --non-interactive install kopete-floor Verbosity 1 Entering non-interactive mode. Initializing Target loading repo resolvables... DONE \ RPM database[100%] Establishing status of aggregates Resolving dependencies... Summary: <install> [S0:0][package]kopete-floor-0.1.0-17.2.i586 Continue? [y/n] y committing Downloading: [S0:0][package]kopete-floor-0.1.0-17.2.i586, -1 B(-1 B unpacked) Downloading: http://software.opensuse.org/download/home:/dmacvicar/openSUSE_Factory/i586… - Downloading[100%] Installing: [S0:0][package]kopete-floor-0.1.0-17.2.i586 | Installing [100%] CommitResult 1 (errors 0, remaining 0, srcremaining 0) real 0m8.925s user 0m7.880s sys 0m0.688s Note: from the 8 seconds, mostly is reading the rpm database. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

6 9

[zypp-devel] ZYPP: TRUNK->BETA REFACTORING-BACKUP-10_3->STABLE
by Michael Andres 20 Jun '07

20 Jun '07

svn copy -r 5789 http://svn.opensuse.org/svn/zypp/trunk/ http://svn.opensuse.org/svn/zypp/branches/REFACTORING-BACKUP-10_3 REFACTORING-BACKUP-10_3 is a snapshot of the latest libzypp revision we comitted to STABLE. TRUNK is now submitted to BETA only, until all the outdated Source* stuff is removed, an all applications switched to the new Repo* classes. How to handle it in YaST? -- 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

2 3

[zypp-devel] Solvererror more verbose
by Stefan Schubert 20 Jun '07

20 Jun '07

Hi, I have enlarged the error messages in order to give the user more feedback _why_ there is an error. This information will be added to "Details". The solver shows information about each item which is involved in an error. (Who has selected, who requires, recommends,.... it) In the last few month we have gotten error messages like: "The solver reports a missing requirement foo. But the package foo_package is available which provides foo. Why the solver does not take this package ?" The answer is that foo_package cannot be taken cause it has own dependency problems. This information will be shown to the user now. In order to give an overview there is an example ( lines without ">!>" shows the new details description): >!> Installing product:openSUSE-factory.i686 from channel 1 >!> Installing pattern:kde.i586 from channel 1 >!> Installing pattern:x11.i586 from channel 1 >!> Installing pattern:base.i586 from channel 1 >!> Installing grub.i586 from channel 1 >!> Installing kernel-default.i586 from channel 1 >!> Installing sendmail from channel 1 >!> Installing postfix from channel 1 >!> 8 problems found: >!> Problem: >!> Cannot install sendmail-8.14.1-23.i586[1] because it is conflicting with postfix >!> A conflict over sendmail == 8.14.1-23 (sendmail) requires the removal of to-be-installed sendmail-8.14.1-23.i586[1] sendmail-8.14.1-23.i586[1] ========================== sendmail-8.14.1-23.i586[1] will be installed by the user. sendmail-8.14.1-23.i586[1] conflicts with postfix postfix-2.4.0-14.i586[1] ======================== postfix-2.4.0-14.i586[1] will be installed by the user. postfix-2.4.0-14.i586[1] is needed by (libpostfix-global.so.1) postfix-2.4.0-14.i586[1] conflicts with sendmail >!> Solution: >!> do not install sendmail >!> do not install sendmail-8.14.1-23.i586[1] >!> Solution: >!> do not install postfix >!> do not install postfix-2.4.0-14.i586[1] >!> Solution: >!> Ignore this conflict of sendmail >!> >!> Problem: >!> Cannot install sendmail-8.14.1-23.i586[1] due to dependency problems >!> sendmail-8.14.1-23.i586[1] is scheduled to be installed, but this is not possible because of dependency problems. sendmail-8.14.1-23.i586[1] ========================== sendmail-8.14.1-23.i586[1] will be installed by the user. sendmail-8.14.1-23.i586[1] conflicts with postfix >!> Solution: >!> do not install sendmail >!> do not install sendmail-8.14.1-23.i586[1] >!> Problem: >!> No valid solution found with only resolvables of best architecture. >!> With this run only resolvables with the best architecture has been regarded. Regarding all possible resolvables takes time but can come to a valid result. >!> Solution: >!> Make a solver run with ALL possibilities. >!> Regarding all resolvables with compatible architecture. >!> Problem: >!> OpenOffice_org-2.2-11.i586[1] cannot be installed due to missing dependencies >!> There are no installable providers of libsndfile.so.1 for OpenOffice_org-2.2-11.i586[1] OpenOffice_org-2.2-11.i586[1] ============================= OpenOffice_org-2.2-11.i586[1] is needed by pattern:kde_office-10.3-61.i586[1] (OpenOffice_org) libsndfile-1.0.17-56.i586[1] provides libsndfile.so.1, but it is uninstallable. Try installing it on its own for more details. >!> Solution: >!> do not install OpenOffice_org >!> do not install OpenOffice_org-2.2-11.i586[1] >!> Solution: >!> Ignore this requirement just here >!> >!> Problem: >!> amarok-1.4.5-57.i586[1] cannot be installed due to missing dependencies >!> There are no installable providers of libtunepimp.so.5 for amarok-1.4.5-57.i586[1] amarok-1.4.5-57.i586[1] ======================= amarok-1.4.5-57.i586[1] is needed by pattern:kde_multimedia-10.3-61.i586[1] (amarok) libtunepimp-0.5.2-50.i586[1] provides libtunepimp.so.5, but it is uninstallable. Try installing it on its own for more details. >!> Solution: >!> do not install amarok >!> do not install amarok-1.4.5-57.i586[1] >!> Solution: >!> Ignore this requirement just here >!> >!> Problem: >!> kaffeine-lang-0.8.4-36.i586[1] cannot be installed due to missing dependencies >!> There are no installable providers of kaffeine == 0.8.4 for kaffeine-lang-0.8.4-36.i586[1] kaffeine-lang-0.8.4-36.i586[1] ============================== kaffeine-lang-0.8.4-36.i586[1] is needed by kaffeine-0.8.4-36.i586[1] (kaffeine-lang == 0.8.4) kaffeine-0.8.4-36.i586[1] provides kaffeine == 0.8.4-36, but it is uninstallable. Try installing it on its own for more details. >!> Solution: >!> do not install kaffeine-lang >!> do not install kaffeine-lang-0.8.4-36.i586[1] >!> Solution: >!> Ignore this requirement just here >!> >!> Problem: >!> kdemultimedia3-3.5.7-16.i586[1] cannot be installed due to missing dependencies >!> There are no installable providers of libakode.so.2 for kdemultimedia3-3.5.7-16.i586[1] kdemultimedia3-3.5.7-16.i586[1] =============================== kdemultimedia3-3.5.7-16.i586[1] is needed by pattern:kde_multimedia-10.3-61.i586[1] (kdemultimedia3) libakode-2.0.2-26.i586[1] provides libakode.so.2, but it is uninstallable. Try installing it on its own for more details. >!> Solution: >!> do not install kdemultimedia3 >!> do not install kdemultimedia3-3.5.7-16.i586[1] >!> Solution: >!> Ignore this requirement just here >!> >!> Problem: >!> pattern:enhanced_base-10.3-61.i586[1] cannot be installed due to missing dependencies >!> There are no installable providers of smtp_daemon for pattern:enhanced_base-10.3-61.i586[1] pattern:enhanced_base-10.3-61.i586[1] ===================================== pattern:enhanced_base-10.3-61.i586[1] is needed by pattern:x11-10.3-61.i586[1] (enhanced_base) exim-4.67-20.i586[1] provides smtp_daemon, but it is uninstallable. Try installing it on its own for more details. >!> Solution: >!> do not install enhanced_base >!> do not install pattern:enhanced_base-10.3-61.i586[1] >!> Solution: >!> Ignore this requirement just here >!> -- ******************************************************************************* 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

1 0

[zypp-devel] [NOTE] -DZYPP_REFACTORING
by Duncan Mac-Vicar Prett 19 Jun '07

19 Jun '07

If you want the download of packages and commit to work, run cmake with that define, because in order to use the new code in commit without break it, we have to ifdef -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

1 0

[zypp-devel] status repository handling
by Duncan Mac-Vicar Prett 19 Jun '07

19 Jun '07

Adding of repositories using data, remote .repo files, removing them is implemented, and the test case is there. Including all the "strange stuff": - you add a repo file from a url, but a file with the same name exists. - you add a repo from a description but a file with the same name of the alias exists - you remove a repo from a file, and in this file there are more repos - etc Editing is not yet there. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

1 0

[zypp-devel] Branches again, this time SLE 10 SP2
by Jan Kupec 19 Jun '07

19 Jun '07

Hi there! There are some bugs in zypper that can't be fixed the same way in 10.3 and SLE 10 SP2. I intend to create SLE 10 SP2 branch for zypper (SLE-10-SP2-Branch) for them (out of SuSE-Linux-10_2-Branch, which we used for SP1 - this will become maintenance branch). I'm posting this so that we discuss and agree on one approach for libzypp, zypper, and others. YaST is branch that way as well. Will this be OK? Cheers, Jano -- 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] 19.6. Status
by Michael Andres 19 Jun '07

19 Jun '07

SVN trunk compiles using gcc4.2. All developers should update to this version (or run build before comitting). Still working and testing the parser and feeding of data into the DB. Reviewing and fixing the SourcePackage handling. Current CacheStore inserts them as ordinary packages, which is plain wrong. We have to start defining how to make locks persistent. I'll prepare a wiki page for 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] status 18.6
by Duncan Mac-Vicar 18 Jun '07

18 Jun '07

- refresh works and it is smart both for downloading the metadata and for building the cache against the metadata. (refresh and cache building for a group of repos that are compeltely up to date , and the cache is a uptodate cache of the metadata takes a second to exit zypper) - still pending: using the old metadata source as cache for Fetcher (no idea how to pass it to downloader and then to fetcher). - addRepo and deleteRepo in progress. - PackageProvider in progress. - in my devel dir testbed.cc you can find a prototype of a ProgressData wrapper that can be used as a progress callback, the idea is, if a function that reports progress has a sub task that also takes a progress callback, and the estimate of this function is X%, then the reports of progress of the sub task are forwarded to the wrapped ProgressData with the corresponded weight. We need this everywhere, Michael, could you please review it and help me with the concept? - Also it would be handy something to get a ProgressData from a MediaSetAccess that teporarely redirects the media reports to the function, michael, is this possible? -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

1 0

[zypp-devel] status 18.6.
by Jan Kupec 18 Jun '07

18 Jun '07

- reimplemented: listrepos (rug service-list) (Duncan) refresh (Duncan) addrepo (rug service-add) search see also ISSUES - ZypperCommand enumeration class added with mappings between zypper and rug commands and aliases. E.g. addrepo - service-add - sa. Cleaner and more flexible code. - code clean-up ISSUES - I'm getting cca 12 secs times for loading preparsed resolvables from db for factory. This means an overall time for install/remove/search commands of 15-20 secs. - Lazy loading (probably) produces hell of a delay when searching in package descriptions (which are not loaded by default, right?) I need to double-check this. Search within NVRAD is quick. Of course, zypper search now just loads all resolvables into memory like it did before (it's just that now it is from preparsed db). This will of course be solved with a full-featured query API, which will later be used by both solver and user searches. Would anybody mind if i looked into this during the Hack Week? Such API would be immediately used by zypper search, and later by solver and searches in YaST package manager (and wherever we need to query database). - solver gives strange results. We probably write some dependencies incorrectly by parsers or we read them incorrectly. See OLD ZYPP, NEW ZYPP with susetags, and NEW ZYPP with yum. But since the results differ between susetags and yum, it is probably the parsers that write wrong data. - We need to replace references to source by RepoInfo (or what) in PoolItem (and maybe elsewhere) I think that's it for now. Continuing fixing the above and dropping the rest of old code from zypper. jano OLD ZYPP $ zypper install gedit .... Summary: <install> [S4:1][package]enchant-1.2.0-74.x86_64 <install> [S4:1][package]gedit-2.18.0-40.x86_64 <uninstall> [S0:0][package]gedit-2.16.1-42.x86_64 NEW ZYPP with susetags factory $ time ./zypper install gedit Summary: <install> [S0:0][package]gnome-audio-2.0.0-177.noarch <install> [S0:0][package]gnome-icon-theme-2.18.0-18.noarch <install> [S0:0][package]gnome-themes-2.18.1-31.noarch <install> [S0:0][package]gnome2-user-docs-2.18.1-31.noarch <install> [S0:0][package]hicolor-icon-theme-0.10-18.noarch <install> [S0:0][package]iso-codes-1.0a-24.noarch <install> [S0:0][package]tango-icon-theme-0.8.0-41.noarch <install> [S0:0][package]DirectFB-1.0.0-32.x86_64 <install> [S0:0][package]Mesa-6.5.3-28.x86_64 <install> [S0:0][package]PolicyKit-0.2_git20060822-73.x86_64 <install> [S0:0][package]SDL-1.2.11-67.x86_64 <install> [S0:0][package]aaa_base-10.3-46.x86_64 <install> [S0:0][package]aaa_skel-2007.3.7-20.x86_64 <install> [S0:0][package]aalib-1.4.0-365.x86_64 <install> [S0:0][package]aspell-0.60.5-26.x86_64 <install> [S0:0][package]aspell-en-6.0-77.x86_64 <install> [S0:0][package]atk-1.18.0-25.x86_64 <install> [S0:0][package]audiofile-0.2.6-61.x86_64 <install> [S0:0][package]audit-libs-1.5.3-14.x86_64 <install> [S0:0][package]avahi-0.6.17-42.x86_64 <install> [S0:0][package]avahi-glib-0.6.17-42.x86_64 <install> [S0:0][package]bash-3.2-35.x86_64 <install> [S0:0][package]cairo-1.4.0-28.x86_64 <install> [S0:0][package]cdparanoia-IIIalpha9.8-609.x86_64 <install> [S0:0][package]cdrdao-1.2.2-81.x86_64 <install> [S0:0][package]cdrkit-cdrtools-compat-1.1.5.1-20.x86_64 <install> [S0:0][package]check-0.9.5-18.x86_64 <install> [S0:0][package]coreutils-6.9-25.x86_64 <install> [S0:0][package]control-center2-2.18.0-42.x86_64 <install> [S0:0][package]cpio-2.6-66.x86_64 <install> [S0:0][package]cracklib-2.8.10-19.x86_64 <install> [S0:0][package]cracklib-dict-small-2.8.10-19.x86_64 <install> [S0:0][package]cups-libs-1.2.11-18.x86_64 <install> [S0:0][package]cyrus-sasl-2.1.22-60.x86_64 <install> [S0:0][package]dbus-1-1.0.2-32.x86_64 <install> [S0:0][package]dbus-1-glib-0.73-27.x86_64 <install> [S0:0][package]dbus-1-x11-1.0.2-37.x86_64 <install> [S0:0][package]desktop-file-utils-0.13-6.x86_64 <install> [S0:0][package]diffutils-2.8.7-64.x86_64 <install> [S0:0][package]dvd+rw-tools-7.0-31.x86_64 <install> [S0:0][package]e2fsprogs-1.39+1.40_WIP_20061114+PATCH20070329-23.x86_64 <install> [S0:0][package]eel-2.18.0.1-35.x86_64 <install> [S0:0][package]enchant-1.2.0-74.x86_64 <install> [S0:0][package]esound-0.2.37-21.x86_64 <install> [S0:0][package]evolution-data-server-1.10.1-33.x86_64 <install> [S0:0][package]fam-2.7.0-54.x86_64 <install> [S0:0][package]file-4.20-25.x86_64 <install> [S0:0][package]fillup-1.42-163.x86_64 <install> [S0:0][package]filesystem-10.3-31.x86_64 <install> [S0:0][package]findutils-4.2.31-7.x86_64 <install> [S0:0][package]fontconfig-2.4.2-26.x86_64 <install> [S0:0][package]freetype2-2.3.4-22.x86_64 <install> [S0:0][package]gail-1.18.0-29.x86_64 <install> [S0:0][package]gconf2-2.18.0.1-29.x86_64 <install> [S0:0][package]gdbm-1.8.3-286.x86_64 <install> [S0:0][package]gedit-2.18.0-40.x86_64 <install> [S0:0][package]genisoimage-1.1.5.1-20.x86_64 <install> [S0:0][package]glib2-2.12.11-22.x86_64 <install> [S0:0][package]glibc-2.6-5.x86_64 <install> [S0:0][package]glitz-0.5.6-62.x86_64 <install> [S0:0][package]gnome-desktop-2.18.1-35.x86_64 <install> [S0:0][package]gnome-keyring-0.8.1-25.x86_64 <install> [S0:0][package]gnome-media-2.18.0-34.x86_64 <install> [S0:0][package]gnome-main-menu-0.9.8-38.x86_64 <install> [S0:0][package]gnome-menus-2.18.0-35.x86_64 <install> [S0:0][package]gnome-mount-0.5-56.x86_64 <install> [S0:0][package]gnome-panel-2.18.1-34.x86_64 <install> [S0:0][package]gnome-python-desktop-2.18.0-39.x86_64 <install> [S0:0][package]gnome-vfs2-2.18.0.1-41.x86_64 <install> [S0:0][package]gnutls-1.6.1-19.x86_64 <install> [S0:0][package]gpm-1.20.1-371.x86_64 <install> [S0:0][package]grep-2.5.2-12.x86_64 <install> [S0:0][package]gstreamer010-0.10.12-29.x86_64 <install> [S0:0][package]gstreamer010-plugins-bad-0.10.4-35.x86_64 <install> [S0:0][package]gstreamer010-plugins-base-0.10.12-36.x86_64 <install> [S0:0][package]gstreamer010-plugins-good-0.10.5-42.x86_64 <install> [S0:0][package]gstreamer010-plugins-ugly-0.10.5-36.x86_64 <install> [S0:0][package]gtk2-2.10.11-27.x86_64 <install> [S0:0][package]gtk2-engines-2.10.0-29.x86_64 <install> [S0:0][package]gtksourceview-1.8.5-26.x86_64 <install> [S0:0][package]hal-0.5.8_git200704021230-36.x86_64 <install> [S0:0][package]icedax-1.1.5.1-20.x86_64 <install> [S0:0][package]info-4.8-71.x86_64 <install> [S0:0][package]insserv-1.09.0-27.x86_64 <install> [S0:0][package]keyutils-libs-1.2-26.x86_64 <install> [S0:0][package]krb5-1.6.1-25.x86_64 <install> [S0:0][package]libFLAC8-1.1.4-21.x86_64 <install> [S0:0][package]libacl-2.2.34-59.x86_64 <install> [S0:0][package]libao-0.8.6-86.x86_64 <install> [S0:0][package]libart_lgpl-2.3.19-19.x86_64 <install> [S0:0][package]libasound2-1.0.14-8.x86_64 <install> [S0:0][package]libattr-2.4.28-65.x86_64 <install> [S0:0][package]libbeagle-0.2.17-21.x86_64 <install> [S0:0][package]libbonobo-2.18.0-21.x86_64 <install> [S0:0][package]libbonoboui-2.18.0-36.x86_64 <install> [S0:0][package]libbz2-1-1.0.4-26.x86_64 <install> [S0:0][package]libcap-1.10-27.x86_64 <install> [S0:0][package]libcdaudio-0.99.12-59.x86_64 <install> [S0:0][package]libcddb-1.3.0-39.x86_64 <install> [S0:0][package]libcdio-0.77-44.x86_64 <install> [S0:0][package]libcom_err-1.39+1.40_WIP_20061114+PATCH20070329-23.x86_64 <install> [S0:0][package]libcroco-0.6.1-48.x86_64 <install> [S0:0][package]libdaemon-0.10-79.x86_64 <install> [S0:0][package]libdb-4_5-4.5.20-12.x86_64 <install> [S0:0][package]libdrm-2.3.0-27.x86_64 <install> [S0:0][package]libdvdnav-0.1.10-58.x86_64 <install> [S0:0][package]libdvdread-0.9.6-46.x86_64 <install> [S0:0][package]libexif-0.6.16-3.x86_64 <install> [S0:0][package]libexpat1-2.0.1-5.x86_64 <install> [S0:0][package]libgcc41-4.1.3_20070521-11.x86_64 <install> [S0:0][package]libgcrypt-1.2.4-22.x86_64 <install> [S0:0][package]libglade2-2.6.0-69.x86_64 <install> [S0:0][package]libgnome-2.18.0-37.x86_64 <install> [S0:0][package]libgnomecanvas-2.14.0-69.x86_64 <install> [S0:0][package]libgnomecups-0.2.2-93.x86_64 <install> [S0:0][package]libgnomekbd-2.18.1-34.x86_64 <install> [S0:0][package]libgnomeprint-2.18.0-24.x86_64 <install> [S0:0][package]libgnomeprintui-2.18.0-28.x86_64 <install> [S0:0][package]libgnomesu-1.0.0-118.x86_64 <install> [S0:0][package]libgnomeui-2.18.1-36.x86_64 <install> [S0:0][package]libgpg-error-1.4-43.x86_64 <install> [S0:0][package]libgsf-1.14.2-76.x86_64 <install> [S0:0][package]libgsm-1.0.10-56.x86_64 <install> [S0:0][package]libgtop-2.14.8-22.x86_64 <install> [S0:0][package]libidl-0.8.8-21.x86_64 <install> [S0:0][package]libjack-0.103.0-33.x86_64 <install> [S0:0][package]libjpeg-6.2.0-796.x86_64 <install> [S0:0][package]libmusicbrainz-2.1.4-45.x86_64 <install> [S0:0][package]libnotify-0.4.4-30.x86_64 <install> [S0:0][package]libnscd-2.0.2-27.x86_64 <install> [S0:0][package]libnvtv-0.4.7a-95.x86_64 <install> [S0:0][package]libogg-1.1.3-58.x86_64 <install> [S0:0][package]liboil-0.3.9-47.x86_64 <install> [S0:0][package]libopencdk-0.5.11-25.x86_64 <install> [S0:0][package]libopenssl0_9_8-0.9.8e-26.x86_64 <install> [S0:0][package]libpng-1.2.12-49.x86_64 <install> [S0:0][package]librsvg-2.16.1-38.x86_64 <install> [S0:0][package]libsexy-0.1.11-26.x86_64 <install> [S0:0][package]libsidplay1-1.36.59-56.x86_64 <install> [S0:0][package]libsmbclient-3.0.25a-13.x86_64 <install> [S0:0][package]libsmbios-libs-0.13.6-2.x86_64 <install> [S0:0][package]libsoup-2.2.100-23.x86_64 <install> [S0:0][package]libstdc++42-4.2.1_20070604-8.x86_64 <install> [S0:0][package]libtheora-0.99.0.7-29.x86_64 <install> [S0:0][package]libtiff-3.8.2-50.x86_64 <install> [S0:0][package]libvisual-0.4.0-63.x86_64 <install> [S0:0][package]libvorbis-1.1.2-59.x86_64 <install> [S0:0][package]libvolume_id-112-6.x86_64 <install> [S0:0][package]libwnck-2.18.0-29.x86_64 <install> [S0:0][package]libxcrypt-2.4-55.x86_64 <install> [S0:0][package]libxklavier-3.0-66.x86_64 <install> [S0:0][package]libxml2-2.6.29-2.x86_64 <install> [S0:0][package]libzio-0.4-27.x86_64 <install> [S0:0][package]lirc-0.8.1_0.8.2pre3-8.x86_64 <install> [S0:0][package]logrotate-3.7.4-46.x86_64 <install> [S0:0][package]lzo-2.02-58.x86_64 <install> [S0:0][package]metacity-2.18.2-32.x86_64 <install> [S0:0][package]mingetty-1.0.7s-9.x86_64 <install> [S0:0][package]mktemp-1.5-788.x86_64 <install> [S0:0][package]mozilla-nspr-4.6.7-4.x86_64 <install> [S0:0][package]mozilla-nss-3.11.6-4.x86_64 <install> [S0:0][package]nautilus-2.18.0.1-38.x86_64 <install> [S0:0][package]nautilus-cd-burner-2.18.1-35.x86_64 <install> [S0:0][package]ncurses-5.6-24.x86_64 <install> [S0:0][package]neon-0.26.3-26.x86_64 <install> [S0:0][package]net-tools-1.60-633.x86_64 <install> [S0:0][package]notification-daemon-0.3.7-31.x86_64 <install> [S0:0][package]nss-mdns-0.9-23.x86_64 <install> [S0:0][package]openSUSE-release-10.3-36.x86_64 <install> [S0:0][package]openldap2-client-2.3.35-17.x86_64 <install> [S0:0][package]openslp-1.2.0-77.x86_64 <install> [S0:0][package]openssl-0.9.8e-26.x86_64 <install> [S0:0][package]openssl-certs-0.9.8e-26.x86_64 <install> [S0:0][package]orbit2-2.14.7-20.x86_64 <install> [S0:0][package]pam-0.99.7.1-28.x86_64 <install> [S0:0][package]pam-modules-10.3-28.x86_64 <install> [S0:0][package]pango-1.16.2-23.x86_64 <install> [S0:0][package]parted-1.8.7-14.x86_64 <install> [S0:0][package]perl-base-5.8.8-60.x86_64 <install> [S0:0][package]permissions-2007.6.12-3.x86_64 <install> [S0:0][package]pm-utils-0.99.3-20.x86_64 <install> [S0:0][package]pmtools-20061026-29.x86_64 <install> [S0:0][package]popt-1.7-344.x86_64 <install> [S0:0][package]pwdutils-3.1.3-38.x86_64 <install> [S0:0][package]python-2.5.1-12.x86_64 <install> [S0:0][package]python-cairo-1.2.2-62.x86_64 <install> [S0:0][package]python-gnome-2.16.0-70.x86_64 <install> [S0:0][package]python-gobject2-2.12.3-35.x86_64 <install> [S0:0][package]python-gtk-2.10.4-20.x86_64 <install> [S0:0][package]python-numeric-24.2-77.x86_64 <install> [S0:0][package]python-orbit-2.14.1-56.x86_64 <install> [S0:0][package]python-xml-2.5.1-12.x86_64 <install> [S0:0][package]readline-5.2-35.x86_64 <install> [S0:0][package]resmgr-1.1.0_SVNr139-2.x86_64 <install> [S0:0][package]sed-4.1.5-48.x86_64 <install> [S0:0][package]shared-mime-info-0.20-24.x86_64 <install> [S0:0][package]slang-2.0.5-58.x86_64 <install> [S0:0][package]sqlite-3.3.17-21.x86_64 <install> [S0:0][package]startup-notification-0.8-75.x86_64 <install> [S0:0][package]sysfsutils-2.1.0-45.x86_64 <install> [S0:0][package]taglib-1.4-87.x86_64 <install> [S0:0][package]sysvinit-2.86-84.x86_64 <install> [S0:0][package]tcpd-7.6-775.x86_64 <install> [S0:0][package]totem-2.18.1-37.x86_64 <install> [S0:0][package]udev-112-6.x86_64 <install> [S0:0][package]wavpack-4.40.0-18.x86_64 <install> [S0:0][package]wireless-tools-29pre21-2.x86_64 <install> [S0:0][package]wodim-1.1.5.1-20.x86_64 <install> [S0:0][package]xorg-x11-libICE-7.2-43.x86_64 <install> [S0:0][package]xorg-x11-libSM-7.2-41.x86_64 <install> [S0:0][package]xorg-x11-libX11-7.2-56.x86_64 <install> [S0:0][package]xorg-x11-libXau-7.2-37.x86_64 <install> [S0:0][package]xorg-x11-libXext-7.2-46.x86_64 <install> [S0:0][package]xorg-x11-libXfixes-7.2-46.x86_64 <install> [S0:0][package]xorg-x11-libXmu-7.2-46.x86_64 <install> [S0:0][package]xorg-x11-libXp-7.2-41.x86_64 <install> [S0:0][package]xorg-x11-libXpm-7.2-45.x86_64 <install> [S0:0][package]xorg-x11-libXprintUtil-7.2-41.x86_64 <install> [S0:0][package]xorg-x11-libXrender-7.2-45.x86_64 <install> [S0:0][package]xorg-x11-libXt-7.2-47.x86_64 <install> [S0:0][package]xorg-x11-libXv-7.2-42.x86_64 <install> [S0:0][package]xorg-x11-libfontenc-7.2-42.x86_64 <install> [S0:0][package]xorg-x11-libs-7.2-74.x86_64 <install> [S0:0][package]xorg-x11-libxcb-7.2-32.x86_64 <install> [S0:0][package]xorg-x11-libxkbfile-7.2-45.x86_64 <install> [S0:0][package]yast2-control-center-gnome-2.13.2-41.x86_64 <install> [S0:0][package]zisofs-tools-1.0.6-59.x86_64 <install> [S0:0][package]zlib-1.2.3-59.x86_64 Continue? [y/n] NEW ZYPP with YUM factory gedit$ ./zypper install gedit 11 Problems: Problem: No valid solution found with only resolvables of best architecture. Problem: zlib-1.2.3-59.x86_64 cannot be installed due to missing dependencies Problem: python-numeric-24.2-77.x86_64 cannot be installed due to missing dependencies Problem: gedit-2.18.0-40.x86_64 cannot be installed due to missing dependencies Problem: python-gnome-2.16.0-70.x86_64 cannot be installed due to missing dependencies Problem: python-gtk-2.10.4-20.x86_64 cannot be installed due to missing dependencies Problem: python-orbit-2.14.1-56.x86_64 cannot be installed due to missing dependencies Problem: python-gobject2-2.12.3-35.x86_64 cannot be installed due to missing dependencies Problem: python-cairo-1.2.2-62.x86_64 cannot be installed due to missing dependencies Problem: python-xml-2.5.1-12.x86_64 cannot be installed due to missing dependencies Problem: cairo-1.4.0-28.x86_64 cannot be installed due to missing dependencies Problem: No valid solution found with only resolvables of best architecture. With this run only resolvables with the best architecture has been regarded. Regarding all possible resolvables takes time but can come to a valid result. Solution 1: Make a solver run with ALL possibilities. Regarding all resolvables with compatible architecture. number, (r)etry or (c)ancel> (choosing 1 does not help either) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 2

[zypp-devel] Improve error reports by creating an error stack?
by Michael Andres 18 Jun '07

18 Jun '07

At various locations we catch exceptions and translate them into other exceptions. Would it be helpfull, if we'd create a simple stack of error strings in class Exception? So we could store and propagate the old Exceptions asString and/or asUserString. Something like this: Failed to create repository. -Reason: Failed to parse some file -Reason: Failed to provide some file -Reason: File not found But it's only worth the efford, if the UI is willing to display such multiline stacklike error messages. -- 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

3 3

[zypp-devel] gpg -> gpg2
by Duncan Mac-Vicar Prett 18 Jun '07

18 Jun '07

ZYpp keyring now uses gpg2 instead of gpg. (#284211) -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

1 0

[zypp-devel] [PROPOSAL] adaptation of zypp apps to new repo management API
by Jan Kupec 15 Jun '07

15 Jun '07

Yesterday we (Prague YaST team) had a discussion about how to proceed with adaptation of YaST to the new repository management API of libzypp. First thing to note, the API has yet to mature in the upcoming days, as we test it with zypper and still modify it as needed. _After_ the API is declared done, we propose to proceed as follows: 1. document transition from old API to the new one (a method to method, code to code map) and post to yast-devel. 2. drop the old source management code from libzypp trunk 3. submit libzypp trunk package to BETA (all dependent packages will then fail building and maintainers will get the notice). 4. maintainers of the dependencies adapt their code 5. after tuning, submit all the stuff to STABLE (in time for the last Aplha release) If you are a maintainer of a package affected by the changes in libzypp, please provide feedback on the new API as you start looking at it (probably after publishing the transition document). Cheers, jano -- 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] patch and delta rpms out of resolvable
by Duncan Mac-Vicar Prett 14 Jun '07

14 Jun '07

As part of the download packages port, the delta/patch rpms are not longer taken from the packages API but from all repositories. What does this mean? - You could have repos providing only patch and delta rpms [1] - Patches don't need to specfy delta and patches rpms in the patch metadata. [1] [1]: This means a metadata format needs to be specified ( deltas.xml for repomd.xml ) I hope someone could drive the patch.xml cleanup. Duncan Note: The current format will still be parsed, and patch/delta rpms find inside patches will be inserted to the list of delta and patch rpms provided by the repo where that patch belongs. -- 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] ZYpp lock - where don't we want it?
by Jan Kupec 14 Jun '07

14 Jun '07

Where we don't want a zypp lock? Where we need read access only in general. In particular: - listing known repositories - search (all kinds - listing available updates falls into this category) - other queries like zypper info, zypper patch-info, etc - (other cases?) What's to proper code to call when libzypp client wants to acquire zypp lock? Do we support all the above already, or do we need modifications? This list also applies to read access for non-root users. That means /etc/zypp/repo.d/* and /var/lib/cache/zypp.db must be readable by non-roots. (I can't think of more.) Also, some function for checking whether other app is having the lock would be nice for use even if we don't need the lock. Having that, e.g zypper search could show a warning that the search result can be inaccurate because of another app manipulating zypp data. Cheers, Jano -- 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] milestone success!
by Duncan Mac-Vicar 12 Jun '07

12 Jun '07

Today, Jano had zypper in a state where the package installation was almost working, except for the fact that the commit try to download the package from the Source class. Tonight, after modfying the commit code, I was able to install a package with zypper. Summary: <install> [S0:0][package]kopete-floor-0.1.0-17.1.x86_64 Continue? [y/n] y Downloading: [S0:0][package]kopete-floor-0.1.0-17.1.x86_64, -1 B(-1 B unpacked) Installing: [S0:0][package]kopete-floor-0.1.0-17.1.x86_64 duncan@tarro:/space/suse/build/zypper/src> duncan@tarro:/space/suse/build/zypper/src> rpm -q kopete-floor kopete-floor-0.1.0-17.1 Some notes: - The commit modifications are a real hack, I mean, it tries to download using the first url available only (no AI), and it wont work with patch and deltas because I did not port that part. PackageProvider and SourceProvideFile code is scary and hard to understand and follow. Can we make that simpler? - I had to ignore 25 dependency problems, because the target for some reason is not added to the pool, so nobody provides any of the requirements. Attached, the hack for zypp commit (not commited to svn as it touches the real working commit) -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg)

1 0

[zypp-devel] Re: zypper exclude delta rpms
by Martin Vidner 11 Jun '07

11 Jun '07

On Mon, Jun 11, 2007 at 05:22:50PM +0200, Thomas Saupe wrote: > Hi Martin, > > sorry for the direct mail but I did not find any info about this. No problem, I have pointed to the ML from the Zypper page. > In SuSE 10.1 there was the possibility to exclude delta via: > > YOU_USE_DELTAS=no > > in /etc/sysconfig/onlineupdate > > How is this handeled in openSuSE 10.2? > > Is there any possibility to exclude delta rpms from being fetched via zypper? AFAIK by uninstalling deltarpm.rpm (/usr/bin/applydeltarpm in particular). -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- 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] status
by Jan Kupec 11 Jun '07

11 Jun '07

- adapting zypper to new zypp API started - initial try zypper with install/remove command - getting sql error when calling solver - migrated zypper from autotools to cmake - lost almost one day with gnome updater applet applying Rodrigo Moya's patch TODO after resolving the install issue, other commands (sa, sd, refresh) and code clean-up will follow 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] [PROPOSAL] mirror list, url variables
by Duncan Mac-Vicar Prett 11 Jun '07

11 Jun '07

Reference: http://lists.opensuse.org/zypp-devel/2007-06/msg00006.html In order to implement url variables, and mirror list, which I don't consideer features but semantics we have to implement to "follow" the repoinfo standard, I would like to propose a way to implement url variables and a simple way to extend them. - mirrorlist: easy, we just need to download the list in repomanager and read the urls when refreshing the source or downloading packages. - url variables: easy, we do substitution inside repomanager before downloading data. - url variables "plugins": -> provide the basc ones built-in (arch, releasever, etc) -> in zypp.conf [url-variables] foo=/somescript.sh or by convention (just drop a script in /etc/zypp/urlvars/foo ) What do you think? Duncan -- 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] cmake version small todo
by Duncan Mac-Vicar 11 Jun '07

11 Jun '07

If you use the cmake that comes with 10.2 (2.4.3 iirc) CMake Error: Error in cmake code at trunk/libzypp/doc/autodoc/CMakeLists.txt:55: INSTALL called with unknown mode DIRECTORY This works with cmake 2.4.6 from the build service for 10.2 or factory. If anyone figures out a workaround there that works with the old cmake, please commit, otherwise we will have to set CMAKE_MINIMUM_REQUIRED(VERSION versionNumber [FATAL_ERROR]) to avoid getting the error above, and complain about the cmake version itself. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

3 3

[zypp-devel] missing docs
by Jan Kupec 11 Jun '07

11 Jun '07

Following is a list of docs i had been missing when starting to work on zypper and later on libzypp: - library overview - it's purpose and abilities, what it can offer to the clients (particular functionalities e.g. it can open a repository and load all the resolvables it contains into some structure) and how (intro on using pieces of it in the client code). This should be in one place. [1] and [2] is not enough when it comes to development of client soft and using libzypp and development of libzypp itself. - Vocabulary - Resolvables - what are these and what kinds of them are there? FIXED[1]. - (Installation) Source vs. Catalog vs. Repository terminology explanation. - code organization - what is what in the source dir tree (purpose of the code) FIXED[1] - Class design - info on the design patterns used (Bridge/Impl and others). If the newcomer is not familiar with these, he/she's just lost :O) - compiled zypp devel guide such as: - use logger (MIL << ...) look HERE for docs - use exceptions like this (ZYPP_THROW ...) look HERE for docs - use smart pointers, look HERE for docs - use THESE patterns, look HERE for docs - define callback base structs in ZYppCallbacks.h if you need to communicate or request info from client soft. again, see HERE for docs. - etc... - Class diagram Martin Vidner and I already started to create one while working on zypper, using ArgoUML tool. See doc/libzypp.zargo. You can open the file using ArgoUML, or uznip it and see what's inside. Problem is, the tool still does not support C++, it's not packaged for SUSE, and, well, creating a proper class diagram for libzypp is a huge task. But a printable class diagram with all classes, with at least inheritance, aggregation and composition relations drawn-in would be more than useful. We should agree on one tool (maybe the ArgoUML at last, it is usable) and be responsible for updating it as we modify the API. NOTE: this should document implementation as well as public API! - Code documentation - documentation of Exceptions - when a particular exception is or should be thrown - Resolvables - what does particular resolvable (kind) represent, what is the corresponding piece of data in metadata (susetags/yum impl. separately). - there are probably more, but i can't recall or go through them all now, we should send a notice about missing docs as we come across some. The links: [1] http://en.opensuse.org/Libzypp/Design [2] http://en.opensuse.org/Libzypp/Package_Management Cheers, jano -- 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] patches, atoms, and the delta and patch RPMs in metadata (YUM)
by Jan Kupec 11 Jun '07

11 Jun '07

Hi hackers, while redesigning various parts of libzypp a question has been raised about incosistencies/misdesign we currently have in our YUM metadata extensions and ZYpp regarding patches. INTRO: In metadata, a patch includes atoms: element atoms { (element-package | element-script | element-message)+ }+ and the package element is an extension of a normal yum:package: element-package = element yum:package { package & element-pkgfiles & (element license-to-confirm { localized-string }?) } where pkgfiles are the delta, patch or plain rpm file data. In libzypp, delta and patch rpms are appended to Package which, basically represents a plain rpm package resolvable. The rest of the /patch/atoms/package data is an Atom resolvable (with its own dependencies), a helper resolvable used to resolve patch dependencies. PROBLEMS: Well, for me as writer of the new YUMParser it is just a question of mapping the data to classes in libzypp (ResolvableData). Experienced zypp hackers can add more... SUGGESTIONS: ? Attaching current version of patch.rnc and patch.rng for convenience. See also: http://en.opensuse.org/Libzypp/Patches/Rationale http://en.opensuse.org/Libzypp/Metadata/repomd/patches (not very informative today, but will be expanded) Cheers, Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 3

[zypp-devel] mirrorlist support in zypp?
by Michael E Brown 07 Jun '07

07 Jun '07

Repeat question from yesterday since I got no response: 1) How do I set up a repomd (yum) format repository that is set up using "mirrorlist=URL" in yum? 2) How can I do variable substitution in a URL? I want to set up a repomd repository (using mirrorlist function above) with a URL like: mirrorlist=http://some.domain.com/repo/path/mirror.pl?osver=$releasever&osn… Where "$releasever" is automatically replaced with the OS version. 3) How can I write a plugin to add (two) new variables in the substitution process? I want to set up repositories that are specific to dell system models and have a server-side cgi redirect the client to the correct repo based on the system model. Something like: mirrorlist=http://domain.com/repo/mirrors.pl?vendor=0x1028&model=0x0152&osn… Any pointers would be greatly appreciated. I would like to write something that works with opensuse and sles. -- Michael -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 6

[zypp-devel] Repository handling in installation
by Jiri Srain 07 Jun '07

07 Jun '07

Hi! Find below the document describing what's required from libzypp for installation of the distro. Jiri Repositories in Installation ============================ locilka, 2007-06-06 jsrain, 2007-06-07 This document describes where and how are software repositories used within the installation or update process. Types of Repositories --------------------- There are two basic types of repositories we use: * Base Product - The base product we are installing or updating to * Add-On Products - Additional products * Currently Installed Products - In case of product upgrade Location of Repositories ------------------------ There can be many types of location of repositories. All products, even the base one, can be remote. So we can have these kinds of repository locations: * Local * CD/DVD * ISO on Disk * Unpacked Repository on Disk * Remote * HTTP * FTP * NFS * Samba * ...? Where Do We Need To Handle Sources ---------------------------------- First there is the initial step of the installation: * Base Product It needs to be initialized after the installation mode is selected (either a new installation or an update). We actually only need to create the product entry in ZYPP, no additional information is needed there. The product control file needs to known from the begining of the installation but it is actually copied to the root of the inst-sys. * Add-On Products They can be added just after the installation mode is selected or also during the installation proposal (Add-On Proposal). For these products, installation.xml is downloaded as well as y2update.tgz and the content file of the product is inspected because we need to gather the product name to be shown in the UI. * Currently Installed Products This is a special case of installation - an upgrade. In this step, we don't need to know more than installed product names that are taken from the /etc/SuSE-release file. Then there is the installation/upgrade-proposal step: * Base Product Here we need to know all patterns, packages ... that are part of the product to make a proposal. * Add-On Products The same as for Base Product, patterns and packages need to be known. * Currently Installed Products In case of upgrade, all installed packages need to be known. I guess that installed patterns are not evaluated at all. We might need this information a bit sooner - in the 'Select Desktop' dialog. Then there is the installation Write() state: * Base & Add-On products Here we need to download additional workflows for patterns to merge them into the installation workflow. This means that all patterns on the media need to be known, but patterns need to be known already anyway. * Currently Installed Products We might think about dropping the information about packages installed on the system (in case of update) here. The proposal is already accepted and after the installation, the information will be gathered from the "current" system status. Then a Finish Installation step is called: * Base & Add-On products I'm not sure how Libzypp database with installation repositories used withing inst-sys is copied to the Target system. It's probably done via some Pkg-bindings call either at the end of the installation or rather just after the installation (Write) starts, maybe both. Summary of Needed Information ----------------------------- * When initializing the installation environment and adding Add-On products, the only information we need is the product resolvable (including dependencies). Maybe some product dependencies are needed too but this is solved somewhere in Libzypp. When an additional product has its own control file, it needs to be known but for getting the file Pkg::SourceProvideOptionalFile function is used. Media and product resolvables needs to be available immediatelly (even for the dependency solver), other resolvables can be downloaded/created later in background. If there is a problem with source initialization in two stages (1st media and products, 2nd other resolvables), then - base source must be initialized (meaning solver can perform operations on it) before the first add-on product is added - add-on product source must be initializes in order to finish the add-on media addition (in case of multiple products in source user is asked which one to install) - dependency on other add-on products (added before) must be possible to be checked by the solver If it is not possible (too risky) to perform any operation on background, source addition can be kept as it is (for 10.3) * When the installation/upgrade reaches the installation/update proposal, all resolvables are needed: products, patterns, packages and even maybe patches if an online update source is added as an add-on (that might happen). Downloading these pieces of information can be done in a background process not to disturb user with: | Downloading file ftp://server/some_file... | | [================75%======>______] | That might make the installation faster, mainly when remove Add-On products are user. But there is an exception we need to take care about: If the product is on a removable media (CD/DVD/USB...?), we need to 'download' all the resolvables before changing the media (but only when we need to change the media because of, e.g., Add-On on another CD). * When the installation starts (installing RPMs, and so long...), also patterns of used workflows need to be known. * Either in the inst_finish or when the disk is formatted and installation starts, we need to know all the data to write it to the target disk, e.g., installed products. * During inst_finish, following operations need to be perfomed: Sources Management - move the information about sources to the target - merge information about sources existing before (add as disabled, for 10.3->10.4 beavior can be changed) - move the raw cache to the target Database - move to the target - merge with existing one (10.3->10.4 upgrade) - ensure that old sources are moved to database (immediatelly or at the beginning of 2nd stage) Target - need to convert information about products/patterns/... if not the original XML format is used (upgrade) - conversion may be done earlier, but definitly after the instlalation proposal -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

1 0

[zypp-devel] [ANNOUNCE] zypp2 moved to zypp
by Duncan Mac-Vicar Prett 06 Jun '07

06 Jun '07

We will start playing with zypper in order to support the new repo handling, and that means we need to install the new APIs, therefore, the zypp2/* classes are now in zypp/. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

1 0

[zypp-devel] status
by Jan Kupec 06 Jun '07

06 Jun '07

CacheStore ---------- - most of ResolvableData.h attributes are now stored - added appendBooleanAttribute() (also to ResolvableQuery) - added appendStringContainerAttribute() (also to ResolvableQuery) - ZConfig.cacheDBSplitJoinSeparator() - a separator string for storing lists of strings as one text attribute into db. (See also the following) little things pending: - storing lists/sets of strings: - is ZConfig the right place for cacheDBSplitJoinSeparator()? - what string to use as separator (currently "!@$") - any other solution? - still need to figure out how to store list<Url> (e.g. from Product data). Either we change it to list<string> or we add appendUrlContainerAttribute() to CacheStore (the latter seems like an overhead to me). What do you think? - fix patch_packages and delta_packages tables - repository_id and file checksum type is missing, media_nr to be removed? - consumeSrcPackage - does the same as consumePackage, except that kind is SrcPackage. Is this correct? YUM parser ---------- - moved YUMParser.* from zypp2 to zypp/parser/yum/RepoParser.* - added suse extensions - added RepoParserOpts to control behavior of RepoParser. - added support for user abort request - throwing ParserException on fatal errors - clean-up/comments little things pending: - //package/size: what's 'archive' size of the package (it is neither the rpm file size nor the installed size). Ignoring it for now. - //format/rpm:sourcerpm where to store this? - //format/rpm:header-range what is this? Do we use this data? - //format/file (*) figure out where to store this and what's it about in regard to filelists.xml.gz - //format/suse:dirsizes - what is this? - //format/suse:license-to-confirm - do we really want multiple *different* licenses in *different* languages here? If so, the schema has to be changed. - FIXME: dependencies like <rpm:entry name="/bin/sh" pre="1"> are not stored - connect progress reporting through ZYppCallbacks.h? - move RepoParserOpts out of yum, so that RepoManager can use it for both yum and susetags? Then we would have to find common options for both parsers (like skipChangeLogs, skipFilelists) Big things pending: - I've forgotten tests!! :O( - Fix the rnc schemas of suse extensions, together with other teams, so that the metadata pass validation by these schemas. This is probably something for later stages of the project (?) Summary: both the parser (and probably also susetags) and the cache store are in good shape so we can proceed with other work and fix the above issues as time goes. 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] repomd (yum) mirrorlist and variable replacement support in zypp?
by Michael E Brown 05 Jun '07

05 Jun '07

I am having trouble implementing a couple things in zypp. -- ability to use a yum mirrorlist URL -- ability to substitute variables in the URL Background, I maintain the unofficial Dell Linux repository, which is in repomd format. I have RHEL and SLES packages posted there. For the repos, I need to have it set up to use my mirrors.pl script. I have googled around and searched the mailing list but could not find out how to implement this. Basically, I need to emulate the yum "mirrorlist=URL" functionality. My mirrorlist is at: http://linux.dell.com/repo/software/mirrors.pl?osname=sles10 My next problem is that yum allows you to embed variables in the URLs that will be replaced. For example "$releasever" is replaced with the OS release version, "$basearch" would be replaced with "i386" or "x86_64" depending on your arch. For Fedora 7, it would resolve to "7". You can write a plugin to yum to extend it with additional variables. I have written a yum plugin to create variables representing the system manufacturer and system model. This enables my Linux hardware repository at http://linux.dell.com/repo/hardware/. This repository contains OS- and Hardware-specific driver and update RPMs. For example, the yum config for this repo is: mirrorlist=http://linux.dell.com/repo/hardware/mirrors.pl?sys_ven_id=$sys_v… I would like to know if there is an equivalent way to add this functionality to zypp. (Note this builds on the mirrorlist functionality above, as the mirrorlist cgi script responds with the list of hardware-dependent repositories. -- Michael -- 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] status 04.06
by Duncan Mac-Vicar Prett 05 Jun '07

05 Jun '07

revision 5664 Here you can find a basic workflow working. How does it looks like? (RepoManager_test case) RepoManager manager(opts); list<RepoInfo> repos = manager.knownRepositories(); RepoInfo repo(repos.front()); manager.refreshMetadata(repo); Repository repository; try { repository = manager.createFromCache(repo); } catch ( const RepoNotCachedException &e ) { ZYPP_CAUGHT(e); MIL << "repo " << repo.alias() << " not cached yet. Caching..." << endl; manager.buildCache(repo); repository = manager.createFromCache(repo); } ResStore store = repository.resolvables(); MIL << store.size() << " resolvables" << endl; I am still getting 0 resolvables, unlike in CacheStore_test where I use a custom parse and I insert resolvables via appendResolvables, so I am not sure if it is a YUMParser bug or CacheStore bug.... will look at it. All paths are passed in the RepoManagerOptions parameter, which default to the ZYpp global paths. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

3 3

[zypp-devel] status 01.06
by Duncan Mac-Vicar Prett 01 Jun '07

01 Jun '07

RepoManager is born. Right now it can list repositories and be tested, and the first methods to control the repo management workflow are being implemented. ( cleanMetadata, refreshMetadata, buildCache, cleanCache and createFromCache ) When I get something basic working in the testcase, I will branch zypper to start doing the port, in order to achieve the big milestone of installing a package. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

1 0