Fedora Core 4

[Dag Wieers]

On Wed, 19 Jan 2005, Jeff Spaleta wrote:

> On Thu, 20 Jan 2005 04:12:16 +0100 (CET), Dag Wieers <dag at wieers.com> wrote:
> > I bet you will get more rants than bug reports. Especially if important
> > security fixes are in the pipeline and they are not installed because of a
> > single unrelated problem.
> 
> I'm not talking about unrelated problems... or stopping the full set
> of unrelated transactions cold because of one package problem. I'm
> trying to confine my arguments to the scope of how the broken dep
> wireless-tools  update should be working... without the extra
> complication of additional unrelated transactions.

Yes, and you fail to indicate where Smart does it wrong :) Smart actually 
does what you said it should be doing.


> What I am arguing is that there needs to be an ecoding of an
> understanding of inherent channel policy and inherent inter-channel
> policy to avoid presenting transactions that are clearly only going to
> be presented to the user if there has been a packaging error. This is
> orthogonal to channel priorities or per-package priorties.  We know..
> as competent users.. that updates-releases should never implicitly
> require a removal of a Core package. We know this because this is a
> policy of how updates-released is defined.  The tools like smart
> should be able to codify that knowledge so that clearly contrary
> transactions will not be presented to the user.

In the case of wireless-tools, there would not be any removals if you 
just do an upgrade. The smart-gui would not upgrade to a newer 
wireless-tools because it considers the cost of the removals more 
important for not upgrading, than the gain of a newer wireless-tools.

Unless, of course, you specify that you want to upgrade wireless-tools 
_specifically_. In that case smart-gui will show you exactly _what_ it 
will do and _why_ it will do that. (The removals)


> I as a user should not be shown a transaction that includes the removal 
> of a NetworkManager and kdenetwork from Core because of the busted
> wireless-tools update from updates-released.

Exactly, smart-gui would not show that transaction if you update. It would 
only show you when you select the newer wireless-tools despite what it 
suggests. Did you try this or is this based on how you think Smart works ?


> > Smart has this, look in smart-gui at:
> > 
> >         Edit > Check All Packages
> 
> This does not appear to be what I am trying to describe at all.
> Perhaps if you give me a a few sentences as to what I'm actually
> seeing in this dialog this might clear up my confusion.

Jeff, you removed what you said. Actually what you said did not describe 
what you wanted, it just gave a general disagreement. Here is what you 
said and what I commented on:

> > > There is a better way in my head, involving keeping up with 'channel
> > > policies' instead of 'priorities'.. i just have to find the words
> > > and the time to articulate it. A way that allows smart to do exactly what
> > > it does now when it needs to deal with overlapping addon repos when
> > > you want to install something new... but flags reportable problems
> > > when a channel or group of channels aren't self-consistent when they
> > > should be.

I commented on the self-consistency. The dialog I talked about does 
exactly that. It shows what packages have unresolved dependencies. Sure it 
can be improved, send your suggestions to Gustavo when you succeed in 
formulating them.


> The dialog certaintly didn't notice the wireless-tools update
> deficiency afaict.  I certaintly can't use that dialog to ask
> questions like 'Are there any packages in updates-released that
> require the removal of Core packages to be installed?'

Any older package could be causing the removal of a package that requires 
the newer packager. So that definition would not be good.

What would be useful though, and I'm certainly going to ask Gustavo this,
is that this dialog should show which newer versions would cause other 
newer versions to be uninstalled. (Maybe a special debug-menu is in order)

(In the pretense that a newer package is introduced with the sole aim to 
become updated, because with Smart you could be introducing an older 
package, to fix a situation that RPM fails to detect, and keep the new one 
in the repo :))

That's where Smart differs, it does not only take the E-V-R into 
account. It does not try to force a new version on to you because it 
happens to be available, it looks at what cost. And I understand the 
uncomfortable feeling of this seemingly undeterministic behaviour, but it 
works.

And you can make use of this cleverness if you want to mix repositories.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]