August 2007 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] repo alias vs. name
by Jan Kupec 11 Sep '07

11 Sep '07

Hi, i would like to achieve a new agreement about repository alias and name usage. The *last agreement* is to *use alias internaly* by applications and *present name to the user* (see [1]). YaST now uses the URL as both the alias and the name by default and allows the user to change the name. But then you get a mess like this in zypper: $ zypper sl # | Enabled | Refresh | Type | Name | URI --+---------+---------+-------+-----------------------------------------------------------------------------------+---------------------------------------------------------------------------------- 1 | No | Yes | yast2 | http://download.opensuse.org/distribution/SL-Factory-non-oss/inst-source-ex… | http://download.opensuse.org/distribution/SL-Factory-non-oss/inst-source-ex… 2 | Yes | Yes | yast2 | stable | ftp://dist.suse.de/install/stable-x86 3 | No | Yes | yast2 | http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ | http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ 4 | No | Yes | yast2 | http://download.opensuse.org/distribution/SL-OSS-factory-debug/inst-source-… | http://download.opensuse.org/distribution/SL-OSS-factory-debug/inst-source-… In addition, zypper uses alias to as argment in repo handling commands and options (ok, you can use repo number (after i reimplement it - soon), but then you need to use zypper repos/lr/sl to list them each time). Another thing is, that libzypp names the .repo files in /etc/zypp/repos.d according to the alias, which again creates a mess if urls are used. My *proposal* is to use *alias as a short name* and the *name as a long name*. I.e., to use a user specified *short name/alias* as both alias and name by default, and leave the possibility to change the long name later (if not specified when ading the repo). IMO, this way, the overall user experience (mainly for zypper users but also for YaST users) will increase. If you don't like this idea for some reasons (e.g. the YaST users will need to enter the alias in addition to the URL, although they might like it :O), please, at least let's use something different internally in YaST for the alias, not the URL. Something shorter. [1] https://bugzilla.novell.com/show_bug.cgi?id=298035 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] JFYI: Parsing boolean from string
by Michael Andres 31 Aug '07

31 Aug '07

zypp/base/String.h + /** Parsing boolean from string. + */ + //@{ + /** Return \c true if str is <tt>1, true, yes, on</tt>. */ + bool strToTrue( const std::string & str ); + + /** Return \c false if str is <tt>0, false, no, off</tt>. */ + bool strToFalse( const std::string & str ); + + /** Parse \c str into a bool depending on the default value. + * If the \c default is true, look for a legal \c false string. + * If the \c default is false, look for a legal \c true string. + */ + inline bool strToBool( const std::string & str, bool default_r ) + { return( default_r ? strToFalse( str ) : strToTrue( str ) ); } + //@} bool flag = str::strToBool( "1", false ); -> true bool flag = str::strToBool( "Yes", false ); -> true bool flag = str::strToBool( "on", false ); -> true bool flag = str::strToBool( "true", false ); -> true bool flag = str::strToBool( "otherwise",false ); -> false bool flag = str::strToBool( "0", true ); -> false bool flag = str::strToBool( "no", true ); -> false bool flag = str::strToBool( "OFF", true ); -> false bool flag = str::strToBool( "False", true ); -> false bool flag = str::strToBool( "otherwise",true ); -> true -- 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] Cleaning up YaST log files
by Lukas Ocilka 31 Aug '07

31 Aug '07

Hi, There are several bugreports in bugzilla that YaST logs are still increasing and they're very often impossible to attach them into a bugreport because of 5MB limit. I wrote a simple script that goes through the file given as a parameter and prints the output in this format: Example ------- Log line: 2007-08-27 10:32:48 <0> 10.10.103.73(3944) [parser::susetags] RepoParser.cc(parse):424 ReferenceCounted(@0xb4656f70<=1) Output: $VAR1 = { 'parser::susetags' => { 'RepoParser.cc' => { '0' => { 'count' => 1, 'size' => 72, } ... } ... } ... } The script is not ideal but could provide some hints where to look and which logs to remove or minimize. Without any offense, the biggest 'sinner' ;) is libzypp. I've used y2log-1 from bug #304815 as an example. The format is: Source File | Log Level | Count | Total Size in Bytes QueueItemRequire.cc 1 1956 285.556 0 450 88.196 ContextPool.cc 0 6145 844.020 Exception.cc 5 7807 1.531.198 Resolver.cc 1 6630 886.471 0 12858 1.664.251 MediaCurl.cc 0 5900 968.752 ResolverUpgrade.cc 1 15506 2.675.810 ExternalProgram.cc 0 7479 1.145.172 The log file has 15.601.918 bytes in total... Entries mentioned above are just an example and I know that common libzypp developer can find more information that I did in the output. Both the script and the exemplary output have been attached. Please, remove as much logs (mostly debugging entries) as you can. Thanks Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

5 17

[zypp-devel] Re: [zypp-commit] r7054 - in /trunk/zypper: package/zypper.changes src/zypper-misc.cc
by Jan Kupec 31 Aug '07

31 Aug '07

kkaempf(a)svn.opensuse.org wrote: > Author: kkaempf > Date: Fri Aug 31 14:15:47 2007 > New Revision: 7054 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=7054&view=rev > Log: > - dont prompt for solutions if none are available. > - dont duplicate dependency problems in output. This was intented to give a simple list of problems first, and then go through each of them in detail. It looks bad when there's only one problem, but is very handy for two and more problems: you immediately see how many of them there are and you have a clue it it's worth the effort to try to resolve them! > - indent details by 2 blanks, resolver indents further details > by 4 blanks. > - provide additional details for problems (#306240) > - don't prompt user for every dependency (#304325) > - don't clutter the log with pool lists. > - r 7054 -- 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] Be carefull when using class ProgressData!
by Michael Andres 30 Aug '07

30 Aug '07

Unlike Report/Callback pairs (or not yet used Signal/Slots), ProgressData reports are not guarded against a vanishing reciever. A ProgressData object should have a limited lifetime. It should go out of scope as the task is completed. Preferably it is a variable local to some function. Not a class data member. https://bugzilla.novell.com/show_bug.cgi?id=299680 shows what happens if some ProgressData _ticks is a class data member: Set up to report progress during RepoImpl creation, it is not reset as the task has completed. Far later, as the RepoImpl goes out of scope, the ProgressData object sends it's final 'end of lifetime' report to a receiver that no longer exists. void task( ... ) { ProgressData ticks; // limited lifetime! } If you need to trigger the same ProgressData object within multiple functions, pass it per reference to the functions, ... .. or at least take care ProgressData is reset at the end of the task: #include "zypp/base/DtorReset.h" class RepoImpl { public: void task( ... ) { DtorReset x( _ticks, ProgressData() ); DtorReset y( _taskRunning, false ); _taskRunning = true; // _ticks = ProgressData( 10 ); // Expect range 0 -> 10 _tics.name( "test ticks" ); // Some arbitrary name _tics.sendTo( _fnc ); // Send reports to _fnc _ticks.toMin(); // start sending min (0) longrun(); _ticks.toMax(); } private: void longrun() { while ( ! done ) { ... if ( eror ) throw; ... _ticks.tick(); } } ProgressData _ticks; bool _taskRunning; }; - task initializes _ticks to be a 'new' ProgressData. - longrun is able to access _ticks - DtorReset takes care _ticks is reset at the end of task, even if an exception occurred. DtorReset: - DtorReset takes care _taskRunning is set to 'false' at the end of task, to show that DtorReset is templated, thus not limited to certain types (as long as they are copyable and assignable). DtorReset assigns back some value: DtorReset x( _flag, _flag ); // save and restore later _flag = 0; See also: class AutoDispose. Similar but calls some user defined cleanup function: { AutoDispose<int> fd( 0 ); fd = open( "/tmp/foo" ); if ( fd == -1 ) return; // or error report else fd.setDispose( ::close ); // HERE: fd is guarded. // The file will be closed when fd goes out of scope. // More precise: when fd and all copies obtained from fd // went out of scope. .. // explicit close: fd.resetDispose(); ::close( fd ); fd = -1; } -- 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] shutting down zypp (Fwd)
by Martin Vidner 29 Aug '07

29 Aug '07

Hi, Benji has asked me about the zypp lock: "Product.ycp obtains a lock on the package database, and there doesn't seem to be a way to release it, I've worked around the problem for now." So I remembered the old discussion about the lock and I'm forwarding it from the old closed list. ----- Forwarded message from Martin Vidner <mvidner(a)suse.cz> ----- Date: Thu, 30 Mar 2006 13:24:45 +0200 From: Martin Vidner <mvidner(a)suse.cz> To: zypp-devel(a)suse.de User-Agent: Mutt/1.5.9i Subject: [zypp-devel] shutting down zypp Hi, during the installation, suse_register is called form yast and it calls zmd to manipulate whatever. Therefore we need to let go of zypp. We introduced ZYpp::reset and SourceManager::reset for this on Mar 3. Now, I also need to release the lock. One part of doing it is allocating the lock object dynamically. But it also makes me think that the reset interface needs to be fixed. Like, why is a separate SourceManager::reset needed at all? Why not have it all encapsulated in ZYpp and simply destroy the main interface object? I do not know the library well enough to change it myself. Please help or guide me. -- Martin Vidner, YaST developer SuSE CR, s.r.o. e-mail: mvidner(a)suse.cz Drahobejlova 27 tel:+420-296542390 190 00 Praha 9, Czech Republic http://www.suse.cz ----- End forwarded message ----- ----- Forwarded message from Klaus Kaempf <kkaempf(a)suse.de> ----- Date: Thu, 30 Mar 2006 14:26:19 +0200 From: Klaus Kaempf <kkaempf(a)suse.de> To: zypp-devel(a)suse.de Subject: Re: [zypp-devel] shutting down zypp Cc: * Martin Vidner <mvidner(a)suse.cz> [Mar 30. 2006 13:24]: > Hi, > > during the installation, suse_register is called form yast and it > calls zmd to manipulate whatever. Therefore we need to let go of > zypp. We introduced ZYpp::reset and SourceManager::reset for this on > Mar 3. Magically, this works in the current builds. I do see a "can't aquire lock" in the first call to a libzypp-zmd-backend helper from zmd but the next one succeeds. The initial failure of lock aquisition is probably due to an (too) early start of zmd. > > Now, I also need to release the lock. One part of doing it is > allocating the lock object dynamically. But it also makes me think > that the reset interface needs to be fixed. Like, why is a separate > SourceManager::reset needed at all? Why not have it all encapsulated > in ZYpp and simply destroy the main interface object? Right. I also don't see the need for a separate, public SourceManager::reset(). > > I do not know the library well enough to change it myself. Please > help or guide me. Michael, this is probably your call ;-) Klaus ----- End forwarded message ----- ----- Forwarded message from Martin Vidner <mvidner(a)suse.cz> ----- Date: Thu, 30 Mar 2006 14:31:12 +0200 From: Martin Vidner <mvidner(a)suse.cz> To: zypp-devel(a)suse.de Subject: Re: [zypp-devel] shutting down zypp User-Agent: Mutt/1.5.9i On Thu, Mar 30, 2006 at 02:26:19PM +0200, Klaus Kaempf wrote: > * Martin Vidner <mvidner(a)suse.cz> [Mar 30. 2006 13:24]: > > Hi, > > > > during the installation, suse_register is called form yast and it > > calls zmd to manipulate whatever. Therefore we need to let go of > > zypp. We introduced ZYpp::reset and SourceManager::reset for this on > > Mar 3. > > Magically, this works in the current builds. > > I do see a "can't aquire lock" in the first call to a libzypp-zmd-backend > helper from zmd but the next one succeeds. > > The initial failure of lock aquisition is probably due to an (too) early > start of zmd. Possibly, but it may be that you're seeing a bug (no buzgilla) where the lock was deleted even when not owned. Duncan fixed it in r2749 yesterday at 2 pm. -- Martin Vidner, YaST developer SuSE CR, s.r.o. e-mail: mvidner(a)suse.cz Drahobejlova 27 tel:+420-296542390 190 00 Praha 9, Czech Republic http://www.suse.cz ----- End forwarded message ----- ----- Forwarded message from Michael Andres <ma(a)suse.de> ----- Date: Thu, 30 Mar 2006 16:23:20 +0200 From: Michael Andres <ma(a)suse.de> To: zypp-devel(a)suse.de Subject: Re: [zypp-devel] shutting down zypp Organization: SuSE GmbH, Nuernberg, Germany User-Agent: Mutt/1.5.9i On Thu, Mar 30, Martin Vidner wrote: > Hi, > > during the installation, suse_register is called form yast and it > calls zmd to manipulate whatever. Therefore we need to let go of > zypp. We introduced ZYpp::reset and SourceManager::reset for this on > Mar 3. reset will introduce more problems, than it solves, because we loose information (e.g. about availbale languages). And every change we may apply to zypp will require someone to remember to check and think about how to handle it on reset. The correct way would be to destroy the ZYpp object. And recreate a new one later. Both via ZYppFactory. No ZYpp object, no lock. -- cu, Michael (ma(a)suse.de) +------------------------------------------------------------------+ ----- End forwarded message ----- ----- Forwarded message from Martin Vidner <mvidner(a)suse.cz> ----- Date: Thu, 30 Mar 2006 17:52:21 +0200 From: Martin Vidner <mvidner(a)suse.cz> To: zypp-devel(a)suse.de Subject: Re: [zypp-devel] shutting down zypp User-Agent: Mutt/1.5.9i On Thu, Mar 30, 2006 at 04:23:20PM +0200, Michael Andres wrote: > The correct way would be to destroy the ZYpp object. And recreate a new > one later. Both via ZYppFactory. No ZYpp object, no lock. OK. So, I should - create ZYppFactory::killZYpp () { _instance = 0; } - in pkg-bindings, call it and assign 0 also to the pkg-binding copy of ZYpp::Ptr - make sure I cleared all other references, otherwise zypp survives - move the unlocking from ~ZYppGlobalLock to ~ZYpp. For debugging, how can I ask ZYpp::Ptr how many references it has? -- Martin Vidner, YaST developer SuSE CR, s.r.o. e-mail: mvidner(a)suse.cz Drahobejlova 27 tel:+420-296542390 190 00 Praha 9, Czech Republic http://www.suse.cz ----- End forwarded message ----- ----- Forwarded message from Michael Andres <ma(a)suse.de> ----- Date: Thu, 30 Mar 2006 22:41:17 +0200 From: Michael Andres <ma(a)suse.de> To: zypp-devel(a)suse.de Subject: Re: [zypp-devel] shutting down zypp Organization: SuSE GmbH, Nuernberg, Germany User-Agent: Mutt/1.5.9i On Thu, Mar 30, Martin Vidner wrote: > On Thu, Mar 30, 2006 at 04:23:20PM +0200, Michael Andres wrote: > > The correct way would be to destroy the ZYpp object. And recreate a new > > one later. Both via ZYppFactory. No ZYpp object, no lock. > > OK. So, I should > - create ZYppFactory::killZYpp () { _instance = 0; } No 'kill', call it release. > - in pkg-bindings, call it and assign 0 also to the pkg-binding copy > of ZYpp::Ptr > - make sure I cleared all other references, otherwise zypp survives > - move the unlocking from ~ZYppGlobalLock to ~ZYpp. Despite all possible problems: ZYpp::Impl is the class of interest, not Zypp. ZYpp is just an interface, ZYpp::Impl is the object. And the one who applies the lock, has to release it, so either both in ZYppFactory or both in ZYpp::Impl. not mixed. But,.. No matter what you do, the solution will be weak. Due to the limited ammout of time, we had to drop the assumption, that ZYpp might not be available. Thus all classes that need ZYpp store a ZYpp::Ptr or call getZYpp (as having multiple ZYpp instances is another assumption we had to drop). AFIK no class is using ZYpp is realy prepared to face the fact, that the controling ZYpp might become unavailable or changes. But there is currently no way to unload ZYpp and the objects using it. Esp. Sources and Resolvables created will not go out of scope, even if ZYpp does. So even if no external reference (outside libzyp) to those objects exists, or is used after the ZYpp shutdown (what may or may not lead to abort), we will still have the memory problem. - release() should be removed from the public ZYpp interface (or at least be deprecated, as it does not work). - If release() is removed, ZYppFactory should store a ZYpp::Impl_Ptr instead of ZYpp::Ptr _instance. That way ZYppFactory is still able to class ZYpp::Impl::release(). (better than nothing) - In ZYppFactory::releaseZYpp, call ZYpp::Impl::release(), then set _instance to NULL, and unlock. Everything else is wasted time, as the problem is far larger than making ZYpp go out of scope. -- cu, Michael (ma(a)suse.de) +------------------------------------------------------------------+ ----- End forwarded message ----- ----- Forwarded message from Martin Vidner <mvidner(a)suse.cz> ----- Date: Fri, 31 Mar 2006 11:27:01 +0200 From: Martin Vidner <mvidner(a)suse.cz> To: zypp-devel(a)suse.de Subject: Re: [zypp-devel] shutting down zypp User-Agent: Mutt/1.5.9i I must admit that you got me more confused than I expected at first reading :-/ Here are just the obvious unclear points: On Thu, Mar 30, 2006 at 10:41:17PM +0200, Michael Andres wrote: > - release() should be removed from the public ZYpp interface > (or at least be deprecated, as it does not work). It it possible at all? It is inherited from zypp::base::ReferenceCounted > > - If release() is removed, ZYppFactory should store a ZYpp::Impl_Ptr > instead of ZYpp::Ptr _instance. That way ZYppFactory is still able to > class ZYpp::Impl::release(). (better than nothing) ZYpp::Impl::release() does not exist. I suppose it is because the impl is a shared_ptr instead of an intrusive_ptr. > > - In ZYppFactory::releaseZYpp, call ZYpp::Impl::release(), then set > _instance to NULL, and unlock. > > > Everything else is wasted time, as the problem is far larger than making > ZYpp go out of scope. -- Martin Vidner, YaST developer SuSE CR, s.r.o. e-mail: mvidner(a)suse.cz Drahobejlova 27 tel:+420-296542390 190 00 Praha 9, Czech Republic http://www.suse.cz ----- End forwarded message ----- ----- Forwarded message from Michael Andres <ma(a)suse.de> ----- Date: Fri, 31 Mar 2006 13:01:28 +0200 From: Michael Andres <ma(a)suse.de> To: zypp-devel(a)suse.de Subject: Re: [zypp-devel] shutting down zypp (different approach) Organization: SuSE GmbH, Nuernberg, Germany User-Agent: Mutt/1.5.9i On Fri, Mar 31, Martin Vidner wrote: > > I must admit that you got me more confused than I expected at first > reading :-/ > Here are just the obvious unclear points: We'll provide a special (otherwise deprecated) ZYppFactory call, that returns a ZYpp which must not be used for other purposes than read_only access to data (as it does not check the global lock). The helper needed for suse_register will use this ZYppFactory call. pkg-bindings need not reset/invalidate ZYpp during suse_register. You can proceed as if libzypp had a prefect locking. -- cu, Michael (ma(a)suse.de) +------------------------------------------------------------------+ ----- End forwarded message ----- ----- Forwarded message from Michael Andres <ma(a)suse.de> ----- Date: Fri, 31 Mar 2006 13:02:47 +0200 From: Michael Andres <ma(a)suse.de> To: zypp-devel(a)suse.de Subject: Re: [zypp-devel] shutting down zypp (different approach) Organization: SuSE GmbH, Nuernberg, Germany User-Agent: Mutt/1.5.9i On Fri, Mar 31, Michael Andres wrote: > > On Fri, Mar 31, Martin Vidner wrote: > > > > > I must admit that you got me more confused than I expected at first > > reading :-/ > > Here are just the obvious unclear points: > > > We'll provide a special (otherwise deprecated) ZYppFactory call, that > returns a ZYpp which must not be used for other purposes than > read_only access to data (as it does not check the global lock). > > The helper needed for suse_register will use this ZYppFactory call. > > pkg-bindings need not reset/invalidate ZYpp during suse_register. > > > > You can proceed as if libzypp had a prefect locking. And ZYpp::reset will be removed from the interface (in case pkg-bindings already use it). -- cu, Michael (ma(a)suse.de) +------------------------------------------------------------------+ ----- End forwarded message ----- (afterwards the thread continued to discuss details of the read-only lock) -- 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

2 1

[zypp-devel] --no-deps for zypper in 10.2 code base
by Jan Kupec 28 Aug '07

28 Aug '07

Is it possible to tell (10.2) libzypp to ignore dependency problems? Is this what ProblemSolutionIgnore object is for? E.g. would checking for solver problems and automatically choosing Ignore do the trick? Or would it not? Or is there even easier solution? 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] Re: [zypp-commit] r6911 - /trunk/libzypp/tests/cache/CacheStore_test.cc
by Duncan Mac-Vicar P. 27 Aug '07

27 Aug '07

On Monday 27 August 2007 05:46:08 pm kkaempf(a)svn.opensuse.org wrote: > Author: kkaempf > Date: Mon Aug 27 17:46:08 2007 > New Revision: 6911 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=6911&view=rev > Log: > OUCH ! toplevel "make" doesn't rebuild tests/ No, but make in tests/ does rebuild the library It is intentional too, we dont build the tests by default. You can force it removing the extra parameter in ADD_SSUBDIRECTORY in CmakeLists.txt -- 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] Deprecated Pattern::install_packages() ?
by Katarina Machalkova 27 Aug '07

27 Aug '07

Hola zypp hackers! While building libzypp I've noticed that install_packages() method of Pattern class has become deprecated. So it is stated in related header file: /** \deprecated AFAIK unused old Selection interface method. */ std::set<std::string> install_packages( const Locale & lang = Locale("") ) const ZYPP_DEPRECATED; This is not exactly true, the method is called in zypp::ui::PatternContents, which in turn is used in all UIs to obtain names of the packages to be installed shown by UI to the user, once he/she selects particular pattern for installation. (i.e. go to package selector, select 'Pattern' filter, choose some pattern e.g. YaST development and the packages you'll see in the right panel are obtained with the help of zypp::ui::PatternContents::install_packages() method) Provided that this method is really deprecated, I'm probably supposed to use something else instead, to achieve the same goal in UI ;-) Could you please point me to some other libzypp method I can possibly use, or advise me how to collect names of the packages that will be installed once user select a pattern? Thanks in advance B. P.S.: Cc-ing also HuHa and Michael, since all UIs are currently using this deprecated method -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

9 18

Re: [zypp-devel] listing patches - consider only some repos?
by Cristian Rodriguez 27 Aug '07

27 Aug '07

>Hmm, what if a repo just added patches - you have to download >repomd.xml at least to find out. huh ? I am missing something ? Sure,a repo can "suddenly" start providing patches but why it has to download repomd.xml ? I see it this way at least for HTTP based repos for **patches** related stuff only. 1. if the repo has not changed do nothing, do not refresh nor reload the cache (after all the repo does not contain patches at all) 2. if the repo has changed, perform a a HEAD request to foobar/repodata/patches.xml if returns HTTP 200 refresh and go ahead. 3.repo can suddenly stop providing patches as well, so a similar operation is needed for that case as well. -- Cristian Rodríguez R. SUSE R&D "You don't have to burn books to destroy a culture. Just get people to stop reading them." --Ray Bradbury

2 1