Hi, 2012/12/4 James Antill <james-yum@xxxxxxx>: > Łukasz Tasz <lukasz@xxxxxxx> writes: > >> Hi, >> >> 2012/12/3 James Antill <james-yum@xxxxxxx>: >>> Łukasz Tasz <lukasz@xxxxxxx> writes: >>> >>>> Hi all, >>>> >>>> I have small question, >>>> Let's say about production environment, and update of software. >>>> What is the recommendation, relay on yum metadata handling, and call >>>> all of the time yum update -y --enablerepo=myrepo, >>>> >>>> or to eliminate any kind of risks and to be 100% sure that update will >>>> go smooth call additional yum clean all --enablerepo=myrepo? >>>> >>>> what experts recommends? >>> >>> I'm not sure what the --enablerepo is for? >> >> If repo is disabled, then also for clean it must be enabled. > > I understand what the option does, but not why you need to use > it. Why is the repo. disabled, why do you want to enable it for the > update? Esp. for a production machine it would not be common to change > the enabled repos. a lot without a good reason. Finally machine is installed using software from different vendors, different releases lifecycles. Update of softvare from external vendors is made independently, that's why by default repos are disabled. I don't see anything wrong/strange over here. Some times it's happening that vendors are changing repositories locations, and yum sometimes is not able to fetch rpm's, then "yum clean all --enab...." is fixing the problem. > >>> Anyway, assuming the repos. you are using aren't completely insane >>> then there should be no need to ever call "yum clean". Even in a case >>> where you'd want to turn metadata_expire off, you should only ever >>> need to call "yum clean expire-cache" ... anything more than that >>> implies something is pretty broken. >> >> sometimes pretty broken means simply changed... and metadata does not >> reflect configuration of repos... >> That's why I'm trying to dig for right approach - policy, > > It's hard to tell what you mean. If you update the repo. and need to > see the latest version right now, then: "yum clean expire-cache" will > do that for you ... and it's a valid usecase. > But, in general that's just not needed. For a production environment > you almost certainly want to control what is happening, so you'd have > a "yum upgrade -y" service (maybe in cron, whatever) and then control > how the repos. are updated so only the updates you need are seen by > the clients ... or you'd have something like "yum load-transaction" > where you've pre. tested the transaction on other machines. this may be considered as an option. My general issue was if applying policy that before update procedures in production it's good idea to drop caches or not. If yum clean ... should be used only if cached looks really poisoned. thanks for support Lukasz Tasz > > -- > James Antill -- james@xxxxxxx > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxx > http://lists.baseurl.org/mailman/listinfo/yum _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
