One option smart needs to conquer the world

[Mikus Grinbergs]

|  So, in this case, what I want is 'upgrade everything that can be, but
|  don't remove anything or downgrade anything'. While smart's current
|  behavior makes sense a lot of the times, if a user can't express the
|  kind of behavior  the user wants to see, then the user will not be
|  satisfied.


On Wed, 22 Feb 2006 15:16:17 -0300 Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> > Alternative Policies for 'smart upgrade' would probably be a good
> > thing. For instance, I would really like a policy similar to 'apt
> > upgrade' that does not Remove packages. (apt dist-upgrade is used for
> > an upgrade that can install and remove packages)
> >
> > If there was an option that would prevent downgrading, then the
> > packager of smart for fedora could choose to enable it by default, if
> > they are so concerned. But users could choose what they want.
>
> That's a crazy world. One of the reasons I wrote Smart was to avoid
> explosion when merely downgrading a package would fix the transaction.
> As a user (perhaps a non-conventional one), I always hated having to
> figure out why the transaction wouldn't work myself.
>
> Is that what users want?  Not peforming an operation at all rather than
> being *ASKED* to downgrade a package?  If that's the case, I'll
> implement the flag in Smart that disables that support (and perhaps
> rename the project...).

What bothers me as a user is that currently smart is "monolithic".
I use 'smart --gui' on SuSE 10.0, and have had to manually correct
the choices 'smart' proposed:

 -  Changes to Gnome became available "piecemeal".

    Apparently the previous levels of many Gnome packages were marked
    with a dependency upon something at version .XX ( but __NOT__
    upon .XX OR GREATER).  When the first set of Gnome updates arrived,
    'smart' proposed to REMOVE dozens of already-installed packages.

    I ended up using 'apt-get' instead (I see no advantage to running
    'smart' from the command line), and 'individually' attempting to
    install the newly-arrived packages -- bypassing those which would
    have caused "important" existing packages to have been REMOVED.

    The next day, *more* updates to Gnome arrived -- and I was able
    to install all the new versions (with by that time I think only
    one previous package still needing to be REMOVED).

 -  The principal (SuSE) repository for "wine" has a corrupted 'wine'
    update package.  When I ran 'smart' it identified a whole list
    of recently updated packages -- including that 'wine' version.
    But it FAILED to install __any__ of that list, because it had
    failed to download the 'wine'.

    I had to manually "mark" the previous 'wine' version as 'kept',
    to avoid 'smart' from including the bad file in its update list.
    *Then* the 'smart' install worked.

 -  I had 'totem' running perfectly satisfactorily on my system.  Yet
    a recent update to something completely different proposed to
    *downgrade* 'totem'.  I had to unmark whatever it was -- I saw
    NO REASON why I should down-level a useable application in order
    to install the latest of an obscure (to me) different package.


As a user, what I want is for 'smart' to PERFORM WHAT IT CAN, and
leave the rest for me to work out for myself (whether through a
dialogue with 'smart', or having me manually 'select' or 'unselect'
candidates for downloading, or whatever).  I __DO NOT WANT__ 'smart'
to avoid performing conflict-free updates because of 'downgrade /
remove' conflicts that the updating of a *few* packages might cause.

[That's what I meant by 'smart' being "monolithic" (i.e., "all or
 nothing").  Clicking on the next-to-rightmost icon (for "figure out
 what's updateable") presents me with a list that is ITSELF not
 configurable.  If there are removes/downgrades, I have to say "yes,
 but not now", then click on 'view marked' and (separately!!) click
 on 'expand', then go through the candidates, unmark and remark them
 individually, and evaluate the results.   Bah !! ]

mikus