January 2008 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] We're going to loose resolvables of kind 'Language'.
by Michael Andres 18 Mar '08

18 Mar '08

We're going to loose resolvables of kind 'Language'. The sat solver allows to handle language supporting packages the way as e.g. hardware supporting packages, via namespaces. So there is no more need to create those dummy language-resolvables. That's nice because the satpool does not allow to have solvables without a repository. So we don't have to create a dummy repository just to maintain those dummy resolvables. The zypp interface will basically stay the same: void setRequestedLocales( const LocaleSet & locales_r ); LocaleSet getRequestedLocales() const; LocaleSet getAvailableLocales() const; May be we add some convenience methods. -- 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 4

[zypp-devel] RFC: ZYpp application layer comments
by Duncan Mac-Vicar P. 08 Feb '08

08 Feb '08

I would like others (especially Michael) to review it. I am quoting the blocks of texts from the Wiki, which I would like to focus the discussion on. >Communication between the YCP application and the C++ package selector widgets is very limited (almost nonexistent). In particular, the YCP application cannot create a pool and pass a handle to that pool to the C++ package selector or vice versa. >Thus, for all important objects like pool or similar, there must be a singleton object for each that can easily be accessed from both the YCP code (via package bindings) and from the package selectors. Those singleton objects should live in the app layer. >Selectables have a higher level status that is the result of the useful permutations of the status flags of their resolvables and the fact whether or not one resolvable from this selectable (one instance of that package) is already installed: >Matching Selectable and Resolvable Status and Candidate Handling >The package selectors use the selectable status. They never store any selectable's status; they always retrieve the status when it is needed. When the user changes a selectable's status, they set new status and retrieve it for display so the display and the selectable status are always in sync. >Since selectable don't exist in the libzypp layer, matching a selectable status to the individual resolvable status flags is done by the app layer and vice versa. The app layer also keeps track of the candidate. This is important when the selectable status is used since some operations (install, update) implicitly operate on the candidate. I think this is one of the central parts of the problem we need to solve. >As long as the user did not explicitly choose a specific candidate, the app layer automatically chooses one from the available resolvables. That automatic choice takes matching architectures and most recent version number into account. This is not trivial. Right now the UIs do this choices in some random code somewhere in the UI, or using the selectable candidate function, which is now incomplete. This kind of decision is the same as the solver local policy. So we have to connect them trough the API somehow. Imagine this something like: bestCandidate( list_of_candidates, task ) Of course this has to be in Selectable, but it has to be connected to the local policy, and it depends on the task you want to execute. Otherwise the UIs will continue breaking things like vendor (the UIs iterate over a package list and select the higher version instead of the best candidate according to the system policies ). >Patterns (collections of packages to fulfil a certain task) This is where the UI <-> library problems starts. What the wiki describes there is the description of a Selection. >Technically, none of those higher level objects has a package content: They all just have dependencies that typically (but not necessarily) are satisfied by packages. Exactly. >From a user's point of view, however, those higher level objects are nothing else than containers for packages. Though this is a somewhat simplistic view, users typically want to see what is behind a pattern, a patch, or a language resolvable. This is why each of them should have a mechanism to enumerate the packages that belong to them. This is true, but only if you can live with the true: the mechanism to enumerate the list of packages is just an algorithm, not a list. It can be false information. That is why I tried to start using the term "related packages" instead of "content". >Enumerate all packages that belong to an RPM group (not just for leaf RPM groups, also those that belong to a higher level like "Productivity") I think the best way to solve this problems is to introduce categories for all resolvabes (tags), in the case of packages it can be implemented using rpm groups, and implement iterators to match full tag, part of it, a collection of them, etc. >Changing the status of a pattern, patch, or language typically affects the status of other resolvables, most notably the packages that belong to this pattern, patch, or language. Those changes should be propagated immediately to those packages so the user can instantly see the effect. >In the past there were calls to just propagate those changes, which worked in most cases, but not in certain pathological ones. But those calls were quick, so for the user there was an instant response. >Recent changes rely on a full solver run to propagate the changes, which gives the correct result in all cases, but which on the other hand is much slower. As some users disable the automatic dependency check because of this, some of them get confused because no change is propagated. There have been bug reports with lively discussions about that. I read this as, we need to do a solver run without doing a solver run? This is a technical limitation, which could be solved of we could for example cheap-ly clone a pool , do something and see the changes, without making the main one dirty. I have no idea yet if that undocumented dirpool has something to do with that ;-) >The user can select any one of those search modes: > > * Contains > * Begins with > * Exact match > * Use wildcards (*, ?) > * Use regular expression > >Case sensitivity in all searches can be switched on or off. > >A query engine to replace this functionality in the UI should enumerate >(return an iterator to) the selectables that match the given criteria. > Update Problems Filter View >This filter view enumerates those packages that for one reason or the other >could not automatically be updated during a system update. Adding packages >to this list is done by the system update application layer. And what is the criteria for searching those? >Libzypp/Application Layer/API Proposal >enum Type { > PACKAGE, > PATTERN, > PATCH, > LANGUAGE > } Why resolvable kind can't be used here? Why the need to duplicate it? > * Create pool iterator (based on the above query as a parameter) > > Pool pool = new Pool (q); So this is like a pool proxy based on a query? Why not the iterator taking the query as a parameter (Michael could comment more?) I have one concern with the design of the pool based on queries. It means we have to load the pool data, this will not be bad with the sat solver, but this is not the same zypper does, as zypper only gets the resolvable data to be displayed on the screen, without any pool. Appart of that the query api seems fine. Other API that could be part of the zypp layer is a command oriented api. If you look what API smart offers to the UIs is a much simpler API, and it is the same the command line tool offers, and this is quite similar to all zypper code. It defines a Command class (install, search, etc) it defines a abstract interface for callbacks (confirm dialogs, progress, questions, etc) The UI simply creates a command and executes it. This is a much simpler approach, but I think it is needed in addition to the layer our selector need. Both packagekit and any app wanting to install a package could benefit from this. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

5 9

[zypp-devel] Re: [zypp-commit] r8405 - /trunk/sat-solver/bindings/satsolver.i
by Michael Schroeder 30 Jan '08

30 Jan '08

On Wed, Jan 30, 2008 at 06:17:16AM -0000, coolo(a)svn.opensuse.org wrote: > Author: coolo > Date: Wed Jan 30 07:17:15 2008 > New Revision: 8405 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8405&view=rev > Log: > fix bindings > > Modified: > trunk/sat-solver/bindings/satsolver.i > > Modified: trunk/sat-solver/bindings/satsolver.i > URL: http://svn.opensuse.org/viewcvs/zypp/trunk/sat-solver/bindings/satsolver.i?… > ============================================================================== > --- trunk/sat-solver/bindings/satsolver.i (original) > +++ trunk/sat-solver/bindings/satsolver.i Wed Jan 30 07:17:15 2008 > @@ -1378,13 +1378,13 @@ > else if (!solver->allowarchchange > && sp->name == sr->name > && sp->arch != sr->arch > - && policy_illegal_archchange(NULL, pool, sp, sr ) ) { > + && policy_illegal_archchange(NULL, sp, sr ) ) { That will result in a null pointer referece, I think. NULL is not a good solver. M. -- 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] r8373 - in /trunk/sat-solver/src: dirpool.c dirpool.h
by Klaus Kaempf 28 Jan '08

28 Jan '08

* mlschroe(a)svn.opensuse.org <mlschroe(a)svn.opensuse.org> [Jan 25. 2008 19:07]: > Author: mlschroe > Date: Fri Jan 25 18:50:39 2008 > New Revision: 8373 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8373&view=rev > Log: > - add dirpool support What is a 'dirpool' and how does it work ? Please add comments and/or documentation below doc/ Klaus -- 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] Read all patterns in 'one go'
by Klaus Kaempf 22 Jan '08

22 Jan '08

Hi, rev 8309 of libzypp now supports to read all patterns in one go. Instead of downloading (and parsing) zillions of little .pat files, one can con'cat'enate all .pat files to a single 'patterns.pat' (resp. 'patterns.pat.gz') file. This fix will hopefully be obsoleted by the new .solv files anytime soon, but until then I hope it might be useful. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

6 10

[zypp-devel] SAT solver testsuite
by Stefan Schubert 21 Jan '08

21 Jan '08

Hi, I have gone through the testcases and following items are currently missed: - "Require <name>" request. If the requirement cannot be fulfilled this missleading error message will be shown: < Encountered problems! Here are the solutions: < < Problem 1: < ==================================== < nothing provides requested notavailable < < - do not install a solvable providing notavailable - If the user installs an addition language ( in an installed system ) the concerning language packages will not be installed. - Additional kernels will be installed although there is already an installed kernel available. (e.G.: ./bugzilla-tests/bug208784-test.xml) - Currently there is no functionality when a pattern will be deleted. (What should happens with the concerning packages ?) - Patch handling has to be completed. - Vendor handling has to be solved/defined. (e.G.: bug310455-test.xml) - The solutions do not have an "ignore" options. Currently about 40 testcases do not work correctly. We are working on it :-) 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

2 1

[zypp-devel] sat pool/stringspace/solver question.
by Michael Andres 16 Jan '08

16 Jan '08

I'd like to have ONE pool/stringspace that contains all the repositories and solvables I'm interested in. I'd like to have several solver instances in parallel, each restricted to operate on a subset of the pools solvables. (i.e. behave as if the pool did not contain anything but this subset.) E.g. temp. disable a repo without need to unload/reload it from the pool, so all solvable ids stay valid. Or solve with/without considering patches. Doable? -- 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 2

[zypp-devel] zypper install foo.rpm now possible (+ rpm file cache zypper/zypp question)
by Jan Kupec 15 Jan '08

15 Jan '08

Hi, i've just finished the support for installation of plain rpm files with zypper (will submitted soon in zypper 0.9.5). It works like this: zypper checks the arguments given to the install command and looks for rpm files among them. If any rpms are found, they are downloaded into one directory and the directory is temporarily added as a plaindir repository. The rpms listed in arguments are ten installed by capability name=version-release fetched from the rpm header. (i'll add more detailed description to the man page soon). example: $ zypper install ~/downloads/foo.rpm http://some.site/path/to/bar.rpm What i'm thinking about now is whether to use a TmpDir, a zypper specific cache dir (e.g. /var/cache/zypper/RPMS) or the future libzypp's rpm file cache dir (in which case the functionality should be provided through libzypp's API together with signature checking, and other security measures) to download the rpms into. Suggestions? Cheers, Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 4

[zypp-devel] satsolver dependency ordering
by Matt Barringer 15 Jan '08

15 Jan '08

Hello, Is the satsolver dependency decision queue populated by solver_solve() ordered in any way? Thanks, Matt -- 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] libzypp - sat integration
by Duncan Mac-Vicar Prett 15 Jan '08

15 Jan '08

I have been looking into libzypp sat solver integration, trying to help with pieces that I am more familiar with. Looking at the code, porting and integrating helps by having a better overview of missing pieces. Right now I have found the following issues/questons. - parsers: There is no parser and attribute storing for plain rpm dirs. And the rpm code is not reusable to do it. (target::rpm in zypp actually is shared between the target and repo::plaindir). Most parsers attribute storing is incomplete too. What I am trying to do is creating a SolvStore that works with the current parsers so I can move blocks without changing much code, and minimize risks when using new pieces (especially if they get complete). It also helps to get familiar with the attribute store. - repo-status The old cache had an attribute per repository which allowed to save the checksum and timestamp of the repo raw metadata index so you could know to which version of the raw metadata the cache was generated from. I will simulate this right now by writing a file $(alias).cookie in the same place as the .solv file I guess. - target the rpm code is not only used to read installed packages. but as I mentioned above, it is used in the plaindir code and also it implements some helpers that deal with patch-rpm querying for installed versions. Ths means basically that target rpm code has to stay or be ported to use information from sat pool. Even if it stays, the keeping rpm and it solv file means changes to the target class and perhaps the repo manager. we store right now installed patterns, patches, and other non-rpm types in a xml store. This would make sense to be ported to a single solv file plus an attribute store, and merge it into the rpm solv and attribute at runtime or on disk. However, this also needs work. - delta rpms and patch rpms libzypp sqlite cache keeps delta and patch rpm information in the database. There are 3 special tables for this. This information has to be stored somewhere. Yes, we could keep a "sqlite part" only for this, but it feels unconfortable. If I can reimplement the CacheStore as a SolvStore, I could stll try to implement the delta and patchrpm metadata as sqlite. Will see. - satsolver-io functions - we need to expose them, right now there is no public api to write a solv file, to read a repo, etc. This is work we need to do _now_. - sat classes and pool string space This is not an issue, but a desgn problem which makes thing unconfortable but there is no "best" solution either. Right now, sat wrapper classes, are only composed of the Id plus some helper methods. For example, architecture as compatibleWith() method, etc. Those classes Id are based on a global "pool". However while parsing (i am talking from the POV of using the current code), you don't want to mess with the global pool. But you want to use those nice classes instead of dealing with dumb objects like as a string as an architecture (yes, to check compatibility right now I have to promote the string to an Arch just to use the helpful methods). Right now those classes can be created being associated to another pool, because then every object would contain data and it would be no "light" anymore. This sucks. That is for now, I will update as I discover more things. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2