[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Fedora Core 4
- From: Dag Wieers <dag wieers com>
- To: Jeff Spaleta <jspaleta gmail com>
- Cc: fedora-devel-list redhat com
- Subject: Re: Fedora Core 4
- Date: Thu, 20 Jan 2005 06:36:00 +0100 (CET)
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
> 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
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]
[Date Prev][Date Next] [Thread Prev][Thread Next]