[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Core 4

On Wed, 19 Jan 2005 14:38:22 -0200, Gustavo Niemeyer
<niemeyer conectiva com> wrote:
> That's exactly the idea. We're all in the same boat, looking at
> the same issues from different angles. Smart has algorithms to
> choose a better possibility given the available options. Jeff
> seems to be looking for a debug tool to detect broken
> distributions.

Actually... im not looking for a debugging tool. I'm looking to find a
balance between ultimate flexibility and robustness in the face of
packaging errors in a way that protects novice users from errors in
situations where errors are obvious based on our human understanding
of how a channel is suppose to operate.  I think we can all pretty
much agree that if a Core updates-released package requires the
removal of a Core package without an explicit obsolete tag being set,
there is a problem there and it should be identified as an error.

Novice users will click their way through pretty much any set of
dialogs you give them, without blinking. If you present this case to a
novice user they will simply do what smart suggests.  And in the
wireless-tools case smart's suggestion is sub-optimal to doing
nothing.  There is absolutely no good reason to provide a simple UI
that encourages average users to commit package update transactions
that are trying to work around internal package conflicts inside Core
+ Updates.  These situations should NEVER happen, and we all know
that. If the end-user tools lets them happen with a simple click of
the mouse, thats a huge usability problem and its going to lead
directly to broken systems.
Flexibility needs to be tempered with robustness to errors.   Point
and click tools aimed at the average user, absolutely need to be
designed to prevent novice users from taking action based on erronous
packaging information as much as possible.

A lot of what smart does when trying to be 'smart' breaks rpm
mechanisms for constraining the dependancy space inside a
self-consistent channel.  smart's logic tries very hard to find a
'best fit' solution to a large multi-repo space but at the cost of
removing consistency checks meant to be used when a channel or a group
of channels is designed to be self-consistent.  Its one thing to be
clever and know that when you want to install a package from atrpms
you should remove a conflicting core package because atrpms and core
are not designed to be self-consistent as a pair. Its quite another to
be so clever that you forget that Core itself is self-consistent and
that Core+Updates-released is suppose to be self-consistent.

What i want is to give smart's flexibility scope based on the
understanding of how a channel is suppose to work and how a channel is
suppose to work with other channels.  installing something from livna,
as a matter of channel policy, shouldn't require the removal of a core
package.. we all know this.. its a stated policy for the livna
channel. The update of a updates-released package shouldn't require
the removal of a core package without an explicit obsolete being
set... we know this.. this is a stated policy of how updates are
suppose to work. These 'policy' definitions for the livna and the
updates-released channel should be respected by packaging tools and
should be used in the calculation of 'best' transaction to avoid
offering any transaction that we know should never be presented to a
user because it HAS to be the result of a packaging error according to
established channel policy for the channels invovled in the
transaction. We must build tools that protect users from errenous
Epochs exist for a reasons... smart breaks the epoch functionality on
purpose to perform superflexible dowgrades... regardless of which
channels are being used in the transaction.
This superflexible epoch ignore shouldn't be used in transactions in a
self-consistent set of channels. There is no good reason to engage in
this level of flexibility if you only have Core and Core Updates as
active channels in the transaction set... this will lead to unexpected
breakage for novice users when package errors are introduced.

Obsolete tags exist for a reason... smart breaks the obsolete
functionality to perform superflexible package removals across
overlapping channels.  There is no good reason to remove Core packages
when updating a Core Update if there isn't an explicit obsolete being
set. This will lead to unexpected breakage for novice users when
package errors are introduced.

Its a matter of finding a way to encode each channel's understood
policy so that smart only offers transactions we are sure are not the
result of packaging errors.  The wireless-tools example is a concrete
example of an offered transaction that should be prevented based on
the expectation of how the updates channel is suppose to work. The
only reason smart offers the transaction it does... is because there
is a packaging error.  Garbage in- garbage out. This situation can be
refined if understood channel policy constraints are used  in smart's
transaction calculation. Since we know Core updates should never need
to remove a Core package without an obsoletes tag, smart should avoid
offering any transaction that would require that.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]