Mailinglist Archive: zypp-devel (230 mails)
| < Previous | Next > |
Re: [zypp-devel] Selectables and 'candidate'
- From: "Duncan Mac-Vicar P." <dmacvicar@xxxxxxx>
- Date: Fri, 08 Feb 2008 12:13:52 +0100
- Message-id: <47AC3970.9020304@xxxxxxx>
Stefan Hundhammer wrote:
"candidate", not selectables per se.
I also question it. I think a Selectable should be grouped by a flexible
policy (name, vendor, edition range, etc) and the candidate accessor
should be removed, if the user selects install, the install request to
the pool should be based on the capabilities of the defined grouping
(requiring the name, the vendor, etc) and doing a solving which could
result in one of the selectable members to transact, and not by a
superficial candidate definition.
The status of the selectable should be simply nothing if no member of
the group transacts, and to be installed, removed if one of the other
members is marked to do so.
Duncan
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
We did that time and again, and the conclusion was always that we NEEDThey are questioning the ultra simplified and broken definition of
something to display to the user.
"candidate", not selectables per se.
I also question it. I think a Selectable should be grouped by a flexible
policy (name, vendor, edition range, etc) and the candidate accessor
should be removed, if the user selects install, the install request to
the pool should be based on the capabilities of the defined grouping
(requiring the name, the vendor, etc) and doing a solving which could
result in one of the selectable members to transact, and not by a
superficial candidate definition.
The status of the selectable should be simply nothing if no member of
the group transacts, and to be installed, removed if one of the other
members is marked to do so.
Duncan
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |