On Wed, 19 Jan 2005, Jeff Spaleta wrote:

On Thu, 20 Jan 2005 04:12:16 +0100 (CET), Dag Wieers dag@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@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]