[Yum] Problem installing multiple rpms

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

 



> What about rpm -F foo.rpm bar.rpm. If you do that and one
> or both packages are up to date rpm ignores the up to date pkg(s)
> and moves on. IMO this is correct behaviour. IOW you can have either behaviour
> you desire. I think this is how things should be. User selectable. At this
> point we can argue this until he#$ freezes over. I think we will have to agree
> to disagree. :-)


Well, I'm enjoying the discussion, b/c I'm trying to figure out what I
think is the most "correct" behavior.

So we can determine what is the default behavior.

right now my general take is this:

rpm installation operations are transaction sets - both in that they are
named that way from rpm internals and in that they have their
deps/conflicts/etc calculated as a SET not individually.

meaning if you ask:

yum update foo bar baz

and they all can be updated but there is some sort of failure in baz
during the install - then it is highly likely that foo and bar will also
fail on the install

look at the hash marking and percentages reported when you run rpm -Uvh
foo.rpm bar.rpm baz.rpm

it marks each of them as 33% of the total.

so they really are a SET of things they are NOT individually dealt with.

so that is where I am right now - so my question is - should pre-rpm
transaction failures be fatal or just warnings.

and/or should that be selectable.

right now yum is failing if it encounters something which is odd about
the transaction set BEFORE it asks rpm if there is anything odd about
it.

I'm inclined to keep that as the default behavior but give the user the
ability to tone down the fatality a bit.

However, I will not consider requests to implement the equiv of --force
--no-deps as eventually slippery-slope states of "toning down the
fatality"


comments?

-sv








[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux