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

Re: [zypp-devel] Deprecated Pattern::install_packages() ?
by Benji Weber 24 Aug '07

24 Aug '07

Oops, havn't subscribed that account. On 24/08/07, Benji Weber <b.weber(a)warwick.ac.uk> wrote: > On 24/08/07, Lukas Ocilka <lukas.ocilka(a)suse.cz> wrote: > > That's true, as a user, I always check which packages a patch/pattern > > contains because I want to know the relation between the patch/pattern > > (name) and its content (what it affected, what else should I select...). > > > > Such statements as "user doesn't want", "user wants", "user needs" > > should be supported by, at least, some mail written to the community at > > factory@opensuse or some Internet survey. > > > > It seems we need to provide surveys *before* we change some important > > parts, or, at least, *after* we change them (however *before* sounds > > better). > > > > Frankly, I've found, that all of us (including myself, of course) are > > "freaks" :) that don't now what the real life is :) ;) We know our > > distribution, we know our packages, we know our source code, but we > > really *don't know* what our users want... > > I quite agree. Surely the design of the user experience should come > first, and then the best means to accomplish that with the API can be > determined. Designing the user experience around the internal design > of the API is madness. > > Now if I understand it correctly the pattern selector will not be > changed for 10.3 in any case? In which case why not post a call to > -project mailing list asking for suggestions & mockups etc. There is > no rush for 10.3++ and asking for input on topics such as this is a > great way to get more people involved. > > _ > Benjamin Weber > -- 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] listing patches - consider only some repos?
by Martin Vidner 24 Aug '07

24 Aug '07

Hi, Cristian Rodriguez noticed that "zypper pch" refreshes all repos, not only those that contain patches (identifiable by repodata/patches.xml). I vaguely remember that we have some optimization for patch-repos already, done by Klaus or Duncan. What is it? -- 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] "uninstallable"
by Martin Vidner 16 Aug '07

16 Aug '07

Hi, this is mostly for Schubi and Klaus I guess. Benji has pointed out that our usage of the term "uninstallable" is confusing: 'You use it to mean "Not installable" I think, but it sounds like "Can be uninstalled".' I have grepped the zypp sources and it looks that mostly we mean Not installable, but in QueueItemUninstall.cc:69 it seems to be the other meaning. Since it is visible to the user in the detailed resolver problem listings, please disambiguate it, probably after 10.3. -- 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

3 2

Re: [zypp-devel] "uninstallable"
by Benji Weber 16 Aug '07

16 Aug '07

> On 16/08/07, Stefan Schubert <schubi(a)suse.de> wrote: > So it is a kind of "revert" which means that that item is "uninstallable". So you're saying that in all cases this means "not installable" rather than "removable" ? _ Benjamin Weber -- 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] zypper se performance
by Benji Weber 13 Aug '07

13 Aug '07

Hi, "zypper se" in svn trunk is still taking quite a long time on my machine, anywhere between 10-20s with main repositories + packman. A simple java test app which queries the /var/cache/zypp/zypp.db database for the name,version,release,repository,arch takes between 1-4s in my tests. Does this lack of performance imply that all resolvables are being read into memory before performing the search, rather than just running the search on the SQLite database? If so, is there any reason for this? _ Benjamin Weber -- 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] making source package & spec
by Duncan Mac-Vicar Prett 08 Aug '07

08 Aug '07

I renamed make autobuild make autobuild_local to make srcpackage make srcpackage_local (to use the same names as zypper) -- 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 - installing source packages from repos
by Jan Kupec 07 Aug '07

07 Aug '07

Zypper (0.8.9) has got a new 'source-install' command: zypper source-install (si) <package_name> ... It reads resolvables of all repos into a ResStore, then iterates through it ByName and ByKind<SrcPackage::kind> and looks for the latest version. Later i will add a possibility to specify version to install, and if it will be demanded then also an ability to install the dependencies along with the source package (through an option perhaps). Also i will add the --repo option to this command as well. Both the yum (after a fix) susetags parser seem to read the source packages correctly. Thanx to this (and the underlying libzypp stuff which Michael provided) 10.3 again has a way to install source packages directly from repos. There is one more thing to fix however: zypper search is currently operating on the ResPool (my beginner's fault i guess, i failed to realize the ResPool should be used for solving only, although Duncan tried to tell me :O). So i have to change it to work on ResStore so that it can be used to search and list also source packages. Cheers, Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] DiskUsage calculation status (libzypp-3.13.12)
by Michael Andres 07 Aug '07

07 Aug '07

DiskUsage status (libzypp-3.13.12) - Provided ResObject interface: + /** + * \short Disk usage per directory + * A common attribute, although mostly packages require + * noticeable disk space. An e.g product could try to reserve + * a certain ammount of diskspace by providing DiskUsage data. + */ + const DiskUsage & diskusage() const; - Prepared classes zypp::repo::cached::PackageImpl zypp::repo::cached::SrcPackageImpl Both overload diskusage(), using a lazy initialized DiskUsage object. By now the object is empty. @Duncan: Please provide a ResolvableQuery to retrieve the du-data from the DB and store them in _diskusage (see #warning FILL DU DATA FROM DB). - Susetags DiskUsage parser is done, and feeds the data to the CacheStore via CacheStore::consumeDiskUsage. Provided CacheStore::consumeDiskUsage stores the data correctly and Duncan prrovides the ResolvableQuery, DiskUsage calculation should work again. -- 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 5

[zypp-devel] ascii art easteregg
by Martin Schlander 07 Aug '07

07 Aug '07

Some of us translators came across the hedgehog easteregg in zypper.. Runesk from Norwegian team created this geeko: http://mose.medisin.ntnu.no/~runesk/geeko.txt Using this tool: http://ascii.mastervb.net/ Maybe it can be used.. of course you have to be fast to not break string freeze ;-) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 7

[zypp-devel] Re: [zypp-commit] r6459 - /trunk/zypper/src/zypper-sources.cc
by Stanislav Visnovsky 06 Aug '07

06 Aug '07

Hi Duncan! Please, document this fact in the man page. Thanks! Stano Dňa Pi 3. August 2007 17:18 dmacvicar(a)svn.opensuse.org napísal: > Author: dmacvicar > Date: Fri Aug 3 17:18:55 2007 > New Revision: 6459 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=6459&view=rev > Log: > - zypper uses tribool internally. So autorefresh and enabled now > have this order of preference: > - cmd line value > - .repo file > - zypp default > > Modified: > trunk/zypper/src/zypper-sources.cc > > Modified: trunk/zypper/src/zypper-sources.cc > URL: > http://svn.opensuse.org/viewcvs/zypp/trunk/zypper/src/zypper-sources.cc?rev >=6459&r1=6458&r2=6459&view=diff > =========================================================================== >=== --- trunk/zypper/src/zypper-sources.cc (original) > +++ trunk/zypper/src/zypper-sources.cc Fri Aug 3 17:18:55 2007 > @@ -366,10 +366,10 @@ > repo.setAlias(alias.empty() ? timestamp() : alias); > repo.addBaseUrl(url); > > - if ( enabled != indeterminate ) > - repo.setEnabled(enabled); > - if ( autorefresh != indeterminate ) > - repo.setAutorefresh(autorefresh); > + if ( !indeterminate(enabled) ) > + repo.setEnabled((enabled == true)); > + if ( !indeterminate(autorefresh) ) > + repo.setAutorefresh((autorefresh == true)); > > return add_repo(repo); > } -- 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] Product type handling
by Jiri Srain 03 Aug '07

03 Aug '07

Hi! As I stated today during the meeting, please, update following way the source parsers in ZYPP: For SuSEtags add to the content file TYPE base for the base product; if not present, it is an add-on product For YUM, we already have in the metadata definition attribute type { text }, which should have values "base" or "add-on"; the parser itself has nandling this attribute commented out. The zypp::Product::category should return the type of the product. Since we broke even source-code compatibility of the library as whole anyway, it may make sense to rename it to zypp::Product::type to be consistent with the metadata. Thanks in advance! Jiri -- 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

2 1

[zypp-devel] option repo.add.probe and repo enablement
by Duncan Mac-Vicar Prett 03 Aug '07

03 Aug '07

I just changed the way repositories are added. Before, zypper probed the repositories in case the --type option was not given, and then always tried to give ZYpp a valid type. However ZYpp also did some probing, so I removed all ZYpper related code. How does it work now? - If type is given, the repository is added and the given type is used. - If zypp.conf repo.add.probe is enabled, the repository is probed either type is given or not - If type is not given the repository is probed no matter if repo.add.probe is off. - if you want to avoid network access completely, always specify the type when adding and set repo.probe.url to 0 - if you want avoid network access when not needed, set repo.probe.url to off, then network will be accessed only if the repository type is unknown. - If you want to always check, set repo.probe.url to 1 Also, zypper autorefresh and enabled options are fixed so the priority is: - what you specified in the command line - the .repo file you are adding - libzypp defaults -- 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] SerialNumber for ResPool.
by Michael Andres 02 Aug '07

02 Aug '07

As we need some serial number indicating a changed ResPool content, I added 2 simple classes SerialNumber and SerialNumberWatcher to zypp/base/SerialNumber.h This should be ok for a simple polling solution. /////////////////////////////////////////////////////////////////// // // CLASS NAME : SerialNumber // /** Simple serial number provider. * * \ref serial returns a serial number. The number returned stays * the same unless \ref setDirty was called to bring the object * into \c dirty state. The next call to \ref serial will increment * the serial number and bring the object into \c clean state. * * \code * SerialNumber sno; * sno.serial(); // SERIAL(0); () = clean * sno.setDirty(); // SERIAL*0*; ** = dirty * sno.serial(); // SERIAL(1) * sno.setDirty(); // SERIAL*1* * sno.setDirty(); // SERIAL*1* * sno.serial(); // SERIAL(2) * \endcode */ /////////////////////////////////////////////////////////////////// // // CLASS NAME : SerialNumberWatcher // /** Simple serial number watcher. * * \ref SerialNumberWatcher remembers a serial number * and tells whenever new numbers you feed change. * * All methods are overloaded to take an \unsigned or a * <tt>const SerialNumber &</tt> as argument. * * \code * SerialNumber sno; * * void check() * { * static SerialNumberWatcher watcher( sno ); * * if ( watcher.remember( sno ) ) * { * cout << "Serial number changed." << endl; * } * } * * int main() * { * check(); // * check(); // * sno.dirty(); * check(); // "Serial number changed." * check(); // * check(); // * sno.dirty(); * check(); // "Serial number changed." * \endcode */ -- 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

Re: [zypp-devel] downgrading with zypper
by Di Pe 01 Aug '07

01 Aug '07

Thanks Jano, the new libzypp brings great speed and feature improvements. I am looking forward to generally use it on 10.2 when all the yast stuff works too. (We won't be able to upgrade all our servers to 10.3 within the next 6 months) dipe > ----- Original Message ----- > From: "Jan Kupec" <jkupec(a)suse.cz> > To: "Di Pe" <dipe(a)mail.com> > Subject: Re: [zypp-devel] downgrading with zypper > Date: Tue, 31 Jul 2007 09:32:57 +0200 > > > Hi, > > please, don't forget to fill Subject in the future. > > Di Pe wrote: > > Hi, I am using zypper 0.83 on opensuse 10.2, have a custom > > repository and installed a new version of sqlite. Everything > > works fine but when I try to downgrade to sqlite 3.38 using the > > 10.2 repository: / # zypper in --catalog dvd sqlite > > The --catalog option is not implemented yet, but will be soon. > > > I could uninstall and reinstall sqlite but guess that would > > really mess up zypper. Not sure if there is any other way to do > > this but I think this would be a really useful feature. > > Yes, specifying version to install/remove is a mandatory feature and is > being implemented right now. In fact you can find the feature in zypper > 0.8.4, but it is yet buggy and needs some more work. What you will be > able to do after its completed is: > > zypper install sqlite = 3.38 > > Jano > -- We've Got Your Name at http://www.mail.com! Get a FREE E-mail Account Today - Choose From 100+ Domains -- 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] Getting rid of boost::regex !?
by Michael Andres 01 Aug '07

01 Aug '07

Coolo asked whether we can get rid of libboost_regex, as it requires to much memory in the instsys (not libboost_regex but the libraries it requires). As far as I see it will affect: KeyRing Edition Applydeltarpm RpmDb Url / UrlBase CapabilityImpl PublicKey MediaSetAccess plaindir/RepoParser This is pretty vital stuff. Who dares to migrate? -- 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

4 5

[zypp-devel] Re: [zypp-commit] r6311 - zypper-sources.cc - base urls iterator
by Jan Kupec 01 Aug '07

01 Aug '07

dmacvicar(a)svn.opensuse.org wrote: > Author: dmacvicar > Date: Mon Jul 30 23:42:43 2007 > New Revision: 6311 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=6311&view=rev > Log: > dont use baseUrls (deprecated, perhaps we remove it) > use the url iterator Let's keep baseUrls(), it's handy for the application to store the set of urls and then work with it if appropriate. Example use case: when initializing repos (checking if to refresh for those with autorefresh enabled), if the app finds out the repo is invalid, it can disable it in its internal set and ignore it for the rest of the operation. But for list repos operation, as is the case below, it is appropriate to use the iterator which always works with data of the *.repo files. Jano > Modified: > trunk/zypper/src/zypper-sources.cc > > Modified: trunk/zypper/src/zypper-sources.cc > URL: http://svn.opensuse.org/viewcvs/zypp/trunk/zypper/src/zypper-sources.cc?rev… > ============================================================================== > --- trunk/zypper/src/zypper-sources.cc (original) > +++ trunk/zypper/src/zypper-sources.cc Mon Jul 30 23:42:43 2007 > @@ -123,10 +123,8 @@ > tr << repo.type().asString(); > tr << repo.alias(); > > - std::set<Url> urls; > - urls = repo.baseUrls(); > - for ( RepoInfo::urls_const_iterator uit = urls.begin(); > - uit != urls.end(); > + for ( RepoInfo::urls_const_iterator uit = repo.baseUrlsBegin(); > + uit != repo.baseUrlsEnd(); > ++uit ) > { > tr << (*uit).asString(); > -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 3

[zypp-devel] Re: [zypp-commit] r6258 - /trunk/zypper/doc/zypper.8
by Jan Kupec 01 Aug '07

01 Aug '07

Hi Klaus, kkaempf(a)svn.opensuse.org wrote: > Author: kkaempf > Date: Fri Jul 27 16:37:21 2007 > New Revision: 6258 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=6258&view=rev > Log: > update manpage for '--from-repo' > > +\fI\--from-repo\fR <repository_alias> > +Limit to updates available from named repository > +.TP this is planned for almost all commands (incl. search, install), not only for update. One reason is for rug compatibility (alias --catalog) and other reason is that it is generally a good thing. But what about naming it just --repo or --repository instead of --from-repo? Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2