Thanks, > I think you might be looking for pkgpolicy=last in your yum.conf. No - I will make certain that my package is newer - at least the version will. But it certainly fixes the problem. Which raises the question: newest? release/version or upload date??? The problem is as follows: When Yellowdog releases a kernel update they should release one for the briQ as well. Currenty 2.4.20-8e. But I am at 2.4.23 soon 2.4.24. But after I post the 2.4.23 on my YUM repository I want the briQs out there to say: 1) .... base is YDL: 2.4.20 (oct 2003) 2) .... update is YDL:2.4.20-8e (jan 2004) 3) .... Total Impact is 2.4.23 (dec 2003) hmmmmmm - 3 is the better one - I will update to that one. (last does fix it!) If YDL released 2.4.24 tomorrow, then I would release 2.4.24-99 right away to counter it for the briQs. On Jan 15, 2004, at 12:38, Garrick Staples wrote: > On Wed, Jan 14, 2004 at 02:27:30PM -0500, seth vidal alleged: >>> The current strategy is as I see it: base, then update. >>> Can this be made a more complex tree? The reason for this is as >>> follows: >>> The briQ is a PPC Open Firmware general industrial computer, which >>> uses >>> basically the same kernel as Apples machines, but sometimes the >>> kernel >>> misbehaves because the briQ has neither keyboard nor monitor. And >>> sometimes this is not adequately tested for by the kernel folks. >>> >>> What I need is YUM to say: check YDL-base, then YDL-update and then >>> Total Impact -update. >> >> make multiple repositories in a yum.conf and have them all in order. >> I think that's what you're describing. > > I think you might be looking for pkgpolicy=last in your yum.conf. > From the > manpage: > > pkgpolicy=[newest|last] > Default: newest. Package sorting order. When a > package is > available from multiple servers, newest will install > the most > recent version of the package found. last will sort the > servers > alphabetically by serverid and install the version of > the pack- > age found on the last server in the resulting list. > If you > don???t understand the above then you???re best left not > including this option at all and letting the default occur. > > I use this is ensure that official RH updates never overwrite rpms in > a local > repo. > > -- > Garrick Staples, Linux/HPCC Administrator > University of Southern California > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum
