Mailinglist Archive: yast-devel (191 mails)

< Previous Next >
Re: [yast-devel] Package-Bindings
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Thu, 20 Mar 2008 01:04:20 +0100
  • Message-id: <20080320000420.GB7202@xxxxxxxxxxxxx>
* Katarina Machalkova <kmachalkova@xxxxxxx> [Mar 19. 2008 23:08]:
Wouldn't you want exactly that - mark packages for which a newer version
appeared on configured repositories in the meantime, as the candidates
for update?

Actually, no.

The distinction is between available and installable updates.

I might be interested in (all) available updates but those actually
installable are of much greater value.

I see your point. Anyway, I don't think it is possible (taking only 'static'
data, not running the solver) to tell in advance whether the package that has
newer version available, is also 'updatable' i.e. if this newer version is
installable at the end.

Without running the solver, I agree.

But users just want to see which package has newer version available (and
which is, at least theoretically, 'updatable'). And they even want to be able
to distinguish between them visually, using e.g. different color or a visual
mark. I recall seeing several (usability related) bugs on this.

Also agreed. I do not want to prevent this mode, it just shouldn't be
the default.

I don't think she's able to decide between updating foo or bar.
The solver, together with the policies defined by the admin, is the
right place for such decisions.

Please note that in UI, marking package for update does not necessarily mean
that this package will be unconditionally updated at the end and the
dependencies get all *cobe*d up because of it.

Of course not, the solver will prevent this. But the feedback from the
solver will be messy ;-)

It is only the means how the user tells the solver 'Hey there, I want you to
update this package for me'. But at the end, it is the solver and its
policies, who is the highest authority there. The one, who performs
dependency check and who might refuse to respect user's decision and not to
update particular pack, even if user wanted it to.

Right. By default, the solver should (and can) assist the user in
selecting the right packages to update.

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >