[zypp-devel] New resolvable state : recommended/suggested

newer
[zypp-devel] Re: [CruiseControl]...

Stefan Schubert

27 Mar 2008 27 Mar '08

18:03

Hi, each resolvable has two new states which are stored in the pool: - recommended - suggested After a solver-run the solver returns a list of recommended/suggested packages which will be installed in the case of recommends. ( OR would be installed if the user has not deselected - keep state) Access: status.isRecommended() status.isSuggested()) Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Show replies by date

Klaus Kaempf

28 Mar 28 Mar

08:09

* Stefan Schubert [Mar 27. 2008 19:03]:

...

Hi, each resolvable has two new states which are stored in the pool:

- recommended - suggested

Nice ! [...]

...

Access:

status.isRecommended() status.isSuggested())

Are there iterators available like 'eachRecommended()' ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stefan Schubert

08:51

Klaus Kaempf schrieb:

...

* Stefan Schubert [Mar 27. 2008 19:03]:

...
Hi, each resolvable has two new states which are stored in the pool:

- recommended - suggested

Nice !

It is a nice new feature of the SAT-solver. I have made it public only :-)

...

[...]

...
Access:

status.isRecommended() status.isSuggested())

Are there iterators available like 'eachRecommended()' ?

A good point.....

...

Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

-- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Klaus Kaempf

08:54

* Stefan Schubert [Mar 28. 2008 09:51]:

...

...
Are there iterators available like 'eachRecommended()' ?

A good point.....

;-) I'd like to reduce (to zero, actually) any loops 'over pool' in zypp applications. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Duncan Mac-Vicar P.

08:56

Klaus Kaempf wrote:

...

* Stefan Schubert [Mar 28. 2008 09:51]:

...
...
Are there iterators available like 'eachRecommended()' ?

A good point.....

;-)

I'd like to reduce (to zero, actually) any loops 'over pool' in zypp applications.

Then why do you recommend a iterator? On what do you want to iterate on then? ( actually, in pool the iterator exists, but needs to be constructed using filter iterator and status filter, this could be wrapped each recommended I think ) Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stefan Schubert

09:01

Duncan Mac-Vicar P. schrieb:

...

Klaus Kaempf wrote:

...
* Stefan Schubert [Mar 28. 2008 09:51]:

...
...
Are there iterators available like 'eachRecommended()' ?

A good point.....

;-)

I'd like to reduce (to zero, actually) any loops 'over pool' in zypp applications.

Then why do you recommend a iterator? On what do you want to iterate on then?

( actually, in pool the iterator exists, but needs to be constructed using filter iterator and status filter, this could be wrapped each recommended I think )

Duncan

I had thought on a new ResFilter kind: ByRecommended and BySuggested -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Klaus Kaempf

09:06

* Duncan Mac-Vicar P. [Mar 28. 2008 09:56]:

...

Klaus Kaempf wrote:

...
I'd like to reduce (to zero, actually) any loops 'over pool' in zypp applications.

Then why do you recommend a iterator? On what do you want to iterate on then?

Because it should hide the actual implementation of 'pool' or how solvables and their state are stored internally. Remember that long-term we want zypp to be 'transaction-based', removing the need of a huge, static, in-memory, mutex-protected data structure holding global state information.

...

( actually, in pool the iterator exists, but needs to be constructed using filter iterator and status filter, this could be wrapped each recommended I think )

Right. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Duncan Mac-Vicar P.

09:22

Klaus Kaempf wrote:

...

Because it should hide the actual implementation of 'pool' or how solvables and their state are stored internally.

Remember that long-term we want zypp to be 'transaction-based', removing the need of a huge, static, in-memory, mutex-protected data structure holding global state information.

I think you are mixing to different things. Pool actually does not show any implementation detail on how solvables are stored. Actually, Pool is an abstraction on top of the sat solver pool, which has a completely different model even for statuses (job based). Pool by itself is a transaction. Pool represent the current transaction. The fact that you can't use the memento pattern to snapshot it and re-apply it does not mean we are not transaction based (and I think that would be tricky, but not impossible to implement) I think the only thing that is missing is an easier way to iterate the transaction (I will start calling the pool transaction since today, to use the new buzz) in order to do something useful with it: like: Pool.each do s if s.isToBeInstalled do foo if s.isToBeDeleted do bar end to Pool.each_to_install do s do foo end Pool.each_to_delete do s do bar end If you see, it is only syntax sugar. What the solver returns from solving is exactly a transaction, which are all statuses on the pool set by user plus the ones set by solver, so I won't start mixing models, that would only confuse people, but see where the APIs make sense to be enhanced (for example, I am not convinced on the example above, it may be cool for python/ruby which have an each construction but in c++ does not make much difference ) So, the current transaction needs always to apply to some living objects. A transaction object need to refer to a package pointer. There either you use the ids (that would make snapshoting the current pool state piececake) or you allow for more highlevel constructions like "kdelibs3", which is no longer a transaction, because if the world changes, that transaction item is no longer valid. You can use strings for jobs (input), but not for the result, because is the solver who needs to tell you exactly which one is to be installed. So a Transaction class alone, would be just a collection of pairs refering to some living object, and what to do with them, and you can get that from the pool (the API to do that could be enhanced for sure). Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Klaus Kaempf

09:38

* Duncan Mac-Vicar P. [Mar 28. 2008 10:22]:

...

Pool.each do s if s.isToBeInstalled do foo if s.isToBeDeleted do bar end

to

Pool.each_to_install do s do foo end Pool.each_to_delete do s do bar end

If you see, it is only syntax sugar.

Well, it _looks_ like more than this. Pool.each do s if s.isToBeInstalled implies that we're looping over a lot of pool items with status just to pick up those few selected for installation. While Pool.each_to_install do s implies that Pool is a handle to the current transaction and each_to_install is a filter on this transaction. To me, the latter is a better architectural model. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Duncan Mac-Vicar Prett

10:15

Klaus Kaempf wrote:

...

Pool.each_to_install do s

implies that Pool is a handle to the current transaction and each_to_install is a filter on this transaction.

Sure, but also implies you have to copy every possible status (or transaction state) to the API. Still, I think those convenience methods are worth it, even if they have little to do with "model" or "architecture", at the end it will look only slightly different at the syntax level (because the fact that sat solver do has a each to install is just coincidence and implementation detail, and how you implement the loop is arguing about microseconds of difference ). Actually, for the UI model, iterating and then comparing the status is much more valuable, because they iterate, and then set icons or colors depending on the status. If they would need to iterate per status, then they would need to do acrobatics using maps to match each items. That is why I insist this is no model or architecture, just convenience methods (and actually for the UI they are still useful to show summaries I guess) Another argument is that only a few pieces iterate looking the different status to do something, because most applications go over commit() which does it for you. What I would like to see improved is the code to inject transactions. think zypper has lot of useful code. The part where it _is_ boring to iterate because unlike commit, each application has to reinvent the wheel, is to set a transaction. Unlike the example above when setting a transaction, you can have nonexistent objects, or strings, so iterating over the pool to find a package and mark it for installation, is duplicated code, instead of using the code zypper has to install by name, capability, etc. So We should really move that code to some libzypp namespace and allow for zypp::install("foo") (and document really well what does this do exactly). Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Klaus Kaempf

10:49

* Duncan Mac-Vicar Prett [Mar 28. 2008 11:16]:

...

Klaus Kaempf wrote:

...
Pool.each_to_install do s

implies that Pool is a handle to the current transaction and each_to_install is a filter on this transaction.

Actually, for the UI model, iterating and then comparing the status is much more valuable, because they iterate, and then set icons or colors depending on the status.

Agreed. The point I was trying to make is that iterating over the whole pool and checking status of pool items doesn't seem to be a good approach to me.

...

If they would need to iterate per status, then they would need to do acrobatics using maps to match each items.

Iteration per status is just one of many possible access methods. It could also be iterate per repository, search result, whatever. And I didn't want to remove status access methods from solvables. So one should still be able to use s.isToBeInstalled. Sorry for being unclear on this.

...

What I would like to see improved is the code to inject transactions. think zypper has lot of useful code. The part where it _is_ boring to iterate because unlike commit, each application has to reinvent the wheel, is to set a transaction. Unlike the example above when setting a transaction, you can have nonexistent objects, or strings, so iterating over the pool to find a package and mark it for installation, is duplicated code, instead of using the code zypper has to install by name, capability, etc. So We should really move that code to some libzypp namespace and allow for zypp::install("foo") (and document really well what does this do exactly).

I couldn't agree more. sat-solver (and sat-solver bindings) already provide a nice (documented) api for this. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Jan Kupec

12:29

New subject: [zypp-devel] convenient API to inject transactions

Duncan Mac-Vicar Prett wrote:

...

What I would like to see improved is the code to inject transactions. think zypper has lot of useful code. The part where it _is_ boring to iterate because unlike commit, each application has to reinvent the wheel, is to set a transaction.

This is half true and half false. The difference is between the GUIs/TUIs and the CLI. The extra code you see in zypper is really needed in zypper only. Here is why: the addRequires(Capability("foo-string")) and addConflicts() is very close to make injecting of transactions a breeze, but there are two major issues with the current API: 1) CLIs need to do a lot of preprocessing to create the Capability themselves (not such a big deal in GUIs and TUIs) 2) The ResolverProblem API lacks access to some information like the type of the problem: - requirement not fulfilled: - user injected (package not found) - required via dependencies (real dependency problem) - addConflict causes no dependency problem (package not installed) And the above really applies (well.. almost) only to CLIs, it happens in GUIs only by programming error, not by user input: - you won't get malformed user input in GUI for which package to install or remove (point 1) - you won't get 'specified package not found' in GUI (point 2) - you won't get 'specified package not installed (point 2) So when thinking of a more convenient API we need to think of the differences between the types of UIs and provide API for all that we can think of (for now CLI and GUI/TUI). so zypp::install(string) { // processing pool.addRequires(Capability(...)); } would always get nice name from GUIs but would need to do the parsing stuff for CLI (with a defined syntax). Also there would have to be zypp::install(Capability) for GUIs to pass exact machine values from their lists and maps when needed. the same for e.g. zypp::lock(string) { // processing Locks.addLock(whatever) } zypp::lock(Capability); and so on for remove, update, reinstall, unlock, keep, etc...

...

Unlike the example above when setting a transaction, you can have nonexistent objects, or strings, so iterating over the pool to find a package and mark it for installation, is duplicated code, instead of

Oh yes, this is what i described in more detail above. I just don't see where is the code duplicated right now. But on the second thought these situations should probably be expected also when the machines (or users through the machines - GUI) do the input. E.g. requesting non-existent object (if you wanted to avoid to do query before requesting and just want to see what happens) this would apply to e.g. a script.

...

using the code zypper has to install by name, capability, etc. So We should really move that code to some libzypp namespace and allow for zypp::install("foo") (and document really well what does this do exactly).

Agreed. Cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Matz

15:06

Hi, On Fri, 28 Mar 2008, Duncan Mac-Vicar P. wrote:

...

Pool by itself is a transaction.

Ehh? No, it isn't. I never understood the use of the word 'transaction' in libzypp (or "an item transacts", which gives me even more creeps). A transaction is a collection of units of work, not a collection of things. A unit of work, when applied to a thing gives you a new think, hence a transaction is comparable to a function, and the pool comparable to a simple set on which a transaction can be applied (giving you a new pool). (For nitpicks: yes, a function also is just a special set, but it's cleaner to differentiate between both concepts).

...

transaction (I will start calling the pool transaction since today, to use the new buzz)

I hope you reconsider. My toenails curl up when I hear that :) Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Jan Kupec

15:16

Michael Matz wrote:

...

Hi,

On Fri, 28 Mar 2008, Duncan Mac-Vicar P. wrote:

...
Pool by itself is a transaction.

Ehh? No, it isn't. I never understood the use of the word 'transaction' in libzypp (or "an item transacts", which gives me even more creeps). A

Yeah, i guess this 'transaction' is just a short version of 'things to be acted upon by the transaction'. So how else should we call it? j.

...

transaction is a collection of units of work, not a collection of things. A unit of work, when applied to a thing gives you a new think, hence a transaction is comparable to a function, and the pool comparable to a simple set on which a transaction can be applied (giving you a new pool).

(For nitpicks: yes, a function also is just a special set, but it's cleaner to differentiate between both concepts).

...
transaction (I will start calling the pool transaction since today, to use the new buzz)

I hope you reconsider. My toenails curl up when I hear that :)

Ciao, Michael.

-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Matz

15:51

Hi, On Fri, 28 Mar 2008, Jan Kupec wrote:

...

Michael Matz wrote:

...
Hi,

On Fri, 28 Mar 2008, Duncan Mac-Vicar P. wrote:

...
Pool by itself is a transaction.

Ehh? No, it isn't. I never understood the use of the word 'transaction' in libzypp (or "an item transacts", which gives me even more creeps). A

Yeah, i guess this 'transaction' is just a short version of 'things to be acted upon by the transaction'. So how else should we call it?

I don't see the distinction to "pool". After all, that's exactly the things to be acted upon. <algebra> Or did you mean that subset of pool that actually changed. I.e. given pool' = trans(pool) did you mean (pool' U pool) \ (pool' intersect pool) ? I'm not readily aware that this set has an agreed upon name. (pool' intersect pool) is related to the kernel of 'trans', hence this whole set is mostly (one element is missing) isomorphic to the quotient (pool U pool')/(ker trans). But calling this set "transaction quotient" would probably also confuse most people. :-) </algebra> Even if you want to make the distinction between "pool" and the above quotient set, you can't call "pool" transaction, because that includes more elements (namely the unchanged ones). Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Duncan Mac-Vicar Prett

15:49

Michael Matz wrote:

...

Hi,

On Fri, 28 Mar 2008, Duncan Mac-Vicar P. wrote:

...
Pool by itself is a transaction.

Ehh? No, it isn't. I never understood the use of the word 'transaction' in libzypp (or "an item transacts", which gives me even more creeps). A transaction is a collection of units of work, not a collection of things. A unit of work, when applied to a thing gives you a new think, hence a transaction is comparable to a function, and the pool comparable to a simple set on which a transaction can be applied (giving you a new pool).

(For nitpicks: yes, a function also is just a special set, but it's cleaner to differentiate between both concepts).

sat solver pool is not, that is why jobs are separated, but the zypp pool is a container of poolitems, each of one has a unit of work (nothing, install, delete), the fact that each poolitem points to an object does not mean the pool itself is only a collection, that pointer is also the receiver of the job, which is part of the job itself. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Andres

15:51

On Fri, Mar 28, Michael Matz wrote:

...

Hi,

On Fri, 28 Mar 2008, Duncan Mac-Vicar P. wrote:

...
Pool by itself is a transaction.

Ehh? No, it isn't. I never understood the use of the word 'transaction' in libzypp (or "an item transacts", which gives me even more creeps). A

Pool is used to build a transaction. Transaction is the collection of packages to be installed/deleted, giving you a new system content. "an item transacts" It is included in the transaction, eiter to be installed or to be deleted. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@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@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Matz

16:04

Hi, On Fri, 28 Mar 2008, Michael Andres wrote:

...

...
Ehh? No, it isn't. I never understood the use of the word 'transaction' in libzypp (or "an item transacts", which gives me even more creeps). A

Pool is used to build a transaction.

Transaction is the collection of packages to be installed/deleted, giving you a new system content.

That's what I thought then. It's strange to call this "transaction", but let's ignore this. It's certainly wrong then to call the pool transaction, though, and only adds more confusion. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Katarina Machalkova

08:25

Ehlo :)

...

Hi, each resolvable has two new states which are stored in the pool:

- recommended - suggested

After a solver-run the solver returns a list of recommended/suggested packages which will be installed in the case of recommends. ( OR would be installed if the user has not deselected - keep state)

I must admit I don't quite understand what does all this mean. 'Recommended' means that the package will be installed, but user is free to decide not to install it later on? What about 'Suggested' then? Does it imply <joke> 'if all goes well, package may be installed?' </joke> Could not find some explanation in Schubi's original mail. Why am I asking: should these new states be somehow reflected in User Interface e.g by icons or status symbols? Or is this meant to be transparent to the user - package is marked for installation and the user does not need to know whether it is because it was 'recommended' or because of something else. I hope I asked clearly enough :) If not, just ask back ;) frozenB. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

Klaus Kaempf

08:34

* Katarina Machalkova [Mar 28. 2008 09:25]:

...

I must admit I don't quite understand what does all this mean. 'Recommended' means that the package will be installed, but user is free to decide not to install it later on?

Right. Its a 'weak requires'. See http://en.opensuse.org/Software_Management/Dependencies for a more elaborate explanation. Suggest is meant as a 'hint to the application, resp. the user' of related packages. Just like Amazons 'Customer who bought this also bought ...'. General rule: Required: Package is marked for installation, de-selection will result in error Recommended: Package is marked for installation, de-selection is allowed Suggested: Package is _not_ marked for installation, application is free to show them as 'related'

...

Why am I asking: should these new states be somehow reflected in User Interface e.g by icons or status symbols? Or is this meant to be transparent to the user - package is marked for installation and the user does not need to know whether it is because it was 'recommended' or because of something else.

It would be helpful to reflect these states and have a "ignore recommends" configuration option for customers requesting a minimal installation. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Duncan Mac-Vicar P.

08:35

Klaus Kaempf wrote:

...

It would be helpful to reflect these states and have a "ignore recommends" configuration option for customers requesting a minimal installation.

According to mls, the solver has such flag. What I am not sure if we set it depending on configuration. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stefan Schubert

08:57

Duncan Mac-Vicar P. schrieb:

...

Klaus Kaempf wrote:

...
It would be helpful to reflect these states and have a "ignore recommends" configuration option for customers requesting a minimal installation.

According to mls, the solver has such flag. What I am not sure if we set it depending on configuration.

Duncan

Yes the SAT-solver has this flag :dontinstallrecommended But currently it will not be set by libzypp. How should this be done by the application ? Is this a new attribute in a pattern ? Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Klaus Kaempf

09:08

* Stefan Schubert [Mar 28. 2008 09:57]:

...

Yes the SAT-solver has this flag :dontinstallrecommended But currently it will not be set by libzypp.

It should be configurable in zypp.conf (defines the default setting) and the application.

...

How should this be done by the application ?

zypp.honorRecommends = true/false

...

Is this a new attribute in a pattern ?

No, it has nothing to do with patterns. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Schroeder

11:32

On Fri, Mar 28, 2008 at 10:08:23AM +0100, Klaus Kaempf wrote:

...

It should be configurable in zypp.conf (defines the default setting) and the application.

...
How should this be done by the application ?

zypp.honorRecommends = true/false

Btw, honorRecommends = false means no language packages, no hardware dependent packages, no split-provides, ... M. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Klaus Kaempf

11:39

* Michael Schroeder [Mar 28. 2008 12:32]:

...

On Fri, Mar 28, 2008 at 10:08:23AM +0100, Klaus Kaempf wrote:

...
It should be configurable in zypp.conf (defines the default setting) and the application.

...
How should this be done by the application ?

zypp.honorRecommends = true/false

Btw, honorRecommends = false means no language packages, no hardware dependent packages, no split-provides, ...

Which is fully acceptable and the right behaviour from my pov. People disabling recommends are usually concerned about the number of packages installed, so they (are supposed to) hand-pick language-packs, drivers, etc. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stephan Kulow

11:58

Am Freitag 28 März 2008 schrieb Klaus Kaempf:

...

* Michael Schroeder [Mar 28. 2008 12:32]:

...
On Fri, Mar 28, 2008 at 10:08:23AM +0100, Klaus Kaempf wrote:

...
It should be configurable in zypp.conf (defines the default setting) and the application.

...
How should this be done by the application ?

zypp.honorRecommends = true/false

Btw, honorRecommends = false means no language packages, no hardware dependent packages, no split-provides, ...

Which is fully acceptable and the right behaviour from my pov.

People disabling recommends are usually concerned about the number of packages installed, so they (are supposed to) hand-pick language-packs, drivers, etc.

Perhaps it would be better to name it zypp.onlyRequires = true/false Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org