Mailinglist Archive: zypp-devel (92 mails)
| < Previous | Next > |
Re: [zypp-devel] Deprecated Pattern::install_packages() ?
- From: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>
- Date: Fri, 24 Aug 2007 12:13:26 +0200
- Message-id: <200708241213.31554.dmacvicar@xxxxxxx>
On Friday 24 August 2007 11:03:39 Stefan Schubert wrote:
> Katarina Machalkova schrieb:
> > 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?
>
> This was a very quick hack and with a lot of unexpected behaviour.
> Now you only have to select the pattern and make a complete solver run.
> The solver will select the concerning packages which you will have to
> pick up then.
That is exactly the point we have been discussing from the beggining.
- ZYpp developers can't accept the fact that someone wants to look
pattern "contents" instead of looking the result of selecting a pattern at
transaction time.
- UI developers insist that patches and patterns have content. While the poor
Patch and Pattern class have no knowledge about that, they just depends on
things, and the solver knows what to grab. It is understandable, because the
UIs were mostly "adapted". A new concept is needed here. I agree at least for
patterns, being able to see packages one by one is really useful, I use it a
lot, but I would call it "related packages", and not the content of the
pattern itself.
- Trying to get a pattern content is like when you buy an electronic product
that requires batteries (not included), and that it also gets enhanced by
some accessory (not required) and pretend to find the batteries and the
accessory in the box. PatternContent goes to the suppermarket really fast and
takes all batteries that match AA and all headphones with jack type X, and
put them into the box, or something like that.
PatternContent is a hack to get that behavior. The code is in Pattern but as
Katarina points out, it does not belong there. The method just iterates along
requires, recommends and suggests and return the capability names if they are
packages, not a very safe method, or call it better "a solver implementation
in 4 lines of code".
The function is deprecated for anyone using the Pattern API. PatternContent is
allowed to do nasty things because it assumes anyone using PatternContent is
a nasty application ;-), we should probably move that "mini-solver" to the
zypp/ui directory.
--
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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
> Katarina Machalkova schrieb:
> > 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?
>
> This was a very quick hack and with a lot of unexpected behaviour.
> Now you only have to select the pattern and make a complete solver run.
> The solver will select the concerning packages which you will have to
> pick up then.
That is exactly the point we have been discussing from the beggining.
- ZYpp developers can't accept the fact that someone wants to look
pattern "contents" instead of looking the result of selecting a pattern at
transaction time.
- UI developers insist that patches and patterns have content. While the poor
Patch and Pattern class have no knowledge about that, they just depends on
things, and the solver knows what to grab. It is understandable, because the
UIs were mostly "adapted". A new concept is needed here. I agree at least for
patterns, being able to see packages one by one is really useful, I use it a
lot, but I would call it "related packages", and not the content of the
pattern itself.
- Trying to get a pattern content is like when you buy an electronic product
that requires batteries (not included), and that it also gets enhanced by
some accessory (not required) and pretend to find the batteries and the
accessory in the box. PatternContent goes to the suppermarket really fast and
takes all batteries that match AA and all headphones with jack type X, and
put them into the box, or something like that.
PatternContent is a hack to get that behavior. The code is in Pattern but as
Katarina points out, it does not belong there. The method just iterates along
requires, recommends and suggests and return the capability names if they are
packages, not a very safe method, or call it better "a solver implementation
in 4 lines of code".
The function is deprecated for anyone using the Pattern API. PatternContent is
allowed to do nasty things because it assumes anyone using PatternContent is
a nasty application ;-), we should probably move that "mini-solver" to the
zypp/ui directory.
--
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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |