useability for dummies

[Mikus Grinbergs]

On Thu, 22 Jun 2006 11:39:00 -0300 Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> > Yesterday I took the time to review the "tracker", to see if anyone
> > had already opened a ticket concerning 'smart' failing to complete
> > an 'Apply' when not all of the requested packets were "clean".
> > (There was such a ticket.)
>
> A lot of people have asked in the past that this become the standard
> behavior, and this will never happen, because what you confirm is
> a transaction, not a set of individual changes. Smart should try
> as hard as possible to either apply the transaction, or nothing at
> all.

I don't understand what your definition of "transaction" is.

In 'smart --gui', I did 'Update', then 'Upgrade' (i.e., 'mark').
That gave me a __list__ (can be seen by View -> Summary) of
packages (at various repositories) that were supposedly at a
more recent version than the packages I had currently installed
on my system.  I consider this a 'list' of what has been updated
at the repositories (and is pertinent to what I have already
installed), *not* a 'transaction'.

Since to me this list __is__ a set of individual changes (what
relationship does a Java update have to a GDM update, unless
explicitly stated in the package's dependencies ??), I dispute
the assertion that what I am seeing here is  ONE  'transaction'.

IF you are going to talk about "confirming", then please allow me to
"exclude" individual line items while I am in the "Summary Window".
Such a capability does exist in the "main window" (e.g., View ->
Hide unmarked, hoping that  View -> Tree style -> Channels ...
has not complicated things), but why should I have to go back to
the "main window" and make my changes there, then click 'Apply'
again to do the "confirming" ?


Despite your saying "this will never happen", let me suggest that
there are users to whom letting 'Apply' automatically (if so
authorized by a parameter / configuration setting) do "as much
as it can" is *preferable* to having 'Apply' abort with an error,
then requiring the users to manually "unmark" the package causing
the error, then re-issue the 'Apply' - while hoping that this time
the install of the remaining packages on the list built by 'Upgrade'
will complete.


mikus