[Yum] yum clean policy question,

[James Antill]

Łukasz Tasz <lukasz at tasz.eu> writes:

> Hi,
>
> 2012/12/3 James Antill <james-yum at and.org>:
>> Łukasz Tasz <lukasz at tasz.eu> 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.

>>  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.

-- 
James Antill -- james at and.org