CentOS - Jul 2010 - "yum update": When is new header data downloaded? (Trying to set up custom repository...)

I'm trying to set up a custom rpm respository for some in-house 
software, and configure a number of CentOS 5 clients so that they may 
install and update the software in question from the location in 
question. I think I've mostly figured out how to do this -  I've 
successfully installed software on one of the clients via "yum install 
<my package>" after adding an URL of the form 
ftp://myserver/pub/<mysoftware> to the list of repositories, and uploading

   1. A directory containing the packages.
   2. A "repodata" directory generated by createrepo.

to the appropriate server location.

But then I wanted to see if could publish an upgrade, too, so I did, on 
the server-side:

   1. Updated the release number in my rpm spec files and rebuilt.
   2. Put the rpms on the right location.
   3. createrepo -q --update <directory>

And on the client

    yum update <my package>

Problem is, this did nothing besides printing the message:

    No Packages marked for Update

So I thought the repository hadn't been properly updated, but then I 
tried (still on the client):

    rm -rf /var/cache/yum/<mysoftware>
    yum update <my package>

And, hey presto, the package was upgraded to the new version.

So, it seems like I managed to correctly update the repodata and all, 
but originally, yum concluded that it didn't need to download a new 
version, but could use the one cached earlier. instead.

Does anyone have any idea why this happened? How exactly does yum decide 
when to download new headers and when to reuse cached data?

Thanks,

- Toralf




This e-mail, including any attachments and response string, may contain
proprietary information which is confidential and may be legally privileged. It
is for the intended recipient only. If you are not the intended recipient or
transmission error has misdirected this e-mail, please notify the author by
return e-mail and delete this message and any attachment immediately. If you are
not the intended recipient you must not use, disclose, distribute, forward,
copy, print or rely on this e-mail in any way except as permitted by the author.

Toralf Lund wrote:
> I'm trying to set up a custom rpm respository for some in-house 
> software, and configure a number of CentOS 5 clients so that they may 
> install and update the software in question from the location in 
> question. I think I've mostly figured out how to do this -  I've 
> successfully installed software on one of the clients via "yum install
> <my package>" after adding an URL of the form 
> ftp://myserver/pub/<mysoftware> to the list of repositories, and
uploading [ ... ]
>
>    
> So, it seems like I managed to correctly update the repodata and all, 
> but originally, yum concluded that it didn't need to download a new 
> version, but could use the one cached earlier.
That should be "a new version *of the repodata*".

- Toralf
>  instead.
>
> Does anyone have any idea why this happened? How exactly does yum decide 
> when to download new headers and when to reuse cached data?
>
> Thanks,
>
> - Toralf
>
>   

This e-mail, including any attachments and response string, may contain
proprietary information which is confidential and may be legally privileged. It
is for the intended recipient only. If you are not the intended recipient or
transmission error has misdirected this e-mail, please notify the author by
return e-mail and delete this message and any attachment immediately. If you are
not the intended recipient you must not use, disclose, distribute, forward,
copy, print or rely on this e-mail in any way except as permitted by the author.

On 07/12/2010 04:58 AM, Toralf Lund wrote:
>
> So, it seems like I managed to correctly update the repodata and all,
> but originally, yum concluded that it didn't need to download a new
> version, but could use the one cached earlier. instead.
>
> Does anyone have any idea why this happened? How exactly does yum decide
> when to download new headers and when to reuse cached data?
>    
You probably want the /etc/yum.conf file. There should be a line in it 
right now that reads 'metadata_expire=1h'.

-- 
Benjamin Franz