Tom Hines wrote:
> I agree with the transaction part, but that's an odd
> definition of update. I agree with Eric. I think the
> definition of update should be:
>
> A:
> preconditions: None.
> postconditions: I have the latest version.
This is not "update." This, moreover, will install a package if it
hasn't been installed yet, seeing as you list preconditions as "None."
> B:
> preconditions: I currently have an old version.
> postconditions: I have the latest version.
That would be the definition of the word "update" in my vocabulary.
Moreover, this is consistent with the way rpm proper handles it:
"rpm -U foo.rpm bar.rpm" will fail if either foo or bar are the
latest version.
> Why should I have to keep track of whether I have the
> latest version of a package? That's not conducive to
> automation.
That's fine with me, but don't call it "update."
> What if I wanted to add some logic in the script
> based on the return value of update? It would be much
> easier if the definition of update was A.
That's questionable. I can think of plenty of examples where I would
WANT for a set of packages to update atomically, or not at all.
> If yum is going to accept multiple packages for the
> update command as in 'yum update pkg1 pkg2 pkg3', then
> I think it should work as in A, because I would expect
> that afterward, I would have the latest version of all
> 3. You know, Principle of Least Surprise, etc.
Really? You find it less surprising if "update" doesn't really update?
--
Konstantin ("Icon") Riabitsev
Duke University Physics Sysadmin
www.phy.duke.edu/~icon/pubkey.asc
