"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'.
On 12 July 2010 13:29, Benjamin Franz jfranz@freerun.com wrote:
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 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Rather than deleting that directory as a whole you would probably be better served by doing a yum clean metadata instead...
James Hogarth wrote:
On 12 July 2010 13:29, Benjamin Franz jfranz@freerun.com wrote:
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'.
Rather than deleting that directory as a whole you would probably be better served by doing a yum clean metadata instead...
I suppose so. I though I might try removing only data for the repository in question rather than clearing the entire cache when testing this, though...
- 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.
Indeed in my case I usually do something akin to ....
yum --disablerepo="*" --enablerepo="myrepo" clean metadata yum -y upgrade --disablerepo="*" --enablerepo="myrepo" mypackage
when updating custom rpms (or RPMs in a specific spacewalk channel) across systems.
On 12 July 2010 15:12, Toralf Lund toralf.lund@pgs.com wrote:
James Hogarth wrote:
On 12 July 2010 13:29, Benjamin Franz jfranz@freerun.com wrote:
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'.
Rather than deleting that directory as a whole you would probably be better served by doing a yum clean metadata instead...
I suppose so. I though I might try removing only data for the repository in question rather than clearing the entire cache when testing this, though...
- 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. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Benjamin Franz wrote:
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'.
Ah. Never noticed this setting before... So only the download time of the data matters, and not the server-side update time? It nearly makes sense then, although the original install was done more than 1h before the update. But maybe the headers were downloaded again after that via yum-updatesd or similar?
A delay of 1h from the repository update to the client can upgrade may not actually be a problem, as long as we know about it...
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.
-
Benjamin Franz -
James Hogarth -
Toralf Lund