Uwe,
Is the media.1/media file on the DVD media supposed to be updated with a time stamp anytime the repository is updated?
If I run a zypper refresh then it only seems to look at the media.1/media file and then doesn't actually parse the rest of the suse/setup/descr/packages* files if it's the same number (timestamp) in there.
I had always assumed the media file was something to be left alone since the create_update script made it.
after changing the timestamp I am now able to run a zypper ref on the repository and get the updates I dropped in. Thanks,
on Wednesday 05 October 2011 Cameron Seader wrote:
Is the media.1/media file on the DVD media supposed to be updated with a time stamp anytime the repository is updated?
If I run a zypper refresh then it only seems to look at the media.1/media file and then doesn't actually parse the rest of the suse/setup/descr/packages* files if it's the same number (timestamp) in there.
I had always assumed the media file was something to be left alone since the create_update script made it.
after changing the timestamp I am now able to run a zypper ref on the repository and get the updates I dropped in. Thanks,
for all I know, zypper is not reading the timestamp of the media.1/media file. I'm not even sure if that would work for http repos.
Zypper is reading the content file of the yast repo and if any of the checksums has changed, it's fetching the meta data again.
The only timestamp that is read is a local one (I don't know where exactly it is) for the implementation of repo.refresh.delay in /etc/zypp/zypp.conf The default is 10 minutes, so it's not doing a refresh if the last one is less than 10 minutes ago - per default.
On Thu, Oct 06, 2011 at 12:26:24PM +0200, Uwe Gansert wrote:
for all I know, zypper is not reading the timestamp of the media.1/media file. I'm not even sure if that would work for http repos.
As the person that asked Cameron the initial question... I'll clarify what I'm seeing (it behaves differently on sle10 vs sle11 too).
We use an updates path for our chosen updates as well as a few additional rpms we use in our image (openafs and a custom rpm that creates a few symlinks for older programs, for example).
Anytime we add or update an rpm in there, update the files via create_package_descr and such.. On SLE10 (SLED 10 SP4 specifically): Running zypper refresh while watching the apache logs on the web server it's using for the repo, all you see are GETs for the media.1/media files, it doesn't even look at content:
[06/Oct/2011:14:48:00 -0700] "GET /x86_64/sled10sp4/updates/media.1/media HTTP/1.1" 200 31 "-" "Novell ZYPP Installer" [06/Oct/2011:14:48:00 -0700] "GET /x86_64/sled10sp4/updates/media.1/media HTTP/1.1" 200 31 "-" "Novell ZYPP Installer"
New rpms are then not seen via a zypper search/install/list-updates/whatever. I even tried just touching the media.1/media file, didn't seem to work, until I updated the value in the media file... then I see it do: [06/Oct/2011:14:52:05 -0700] "GET /x86_64/sled10sp4/updates/media.1/media HTTP/1.1" 200 32 "-" "Novell ZYPP Installer" [06/Oct/2011:14:52:05 -0700] "GET /x86_64/sled10sp4/updates/media.1/directory.yast HTTP/1.1" 200 15 "-" "Novell ZYPP Installer" [06/Oct/2011:14:52:05 -0700] "GET /x86_64/sled10sp4/updates/media.1/media HTTP/1.1" 200 32 "-" "Novell ZYPP Installer" [06/Oct/2011:14:52:05 -0700] "GET /x86_64/sled10sp4/updates/media.1/products HTTP/1.1" 200 44 "-" "Novell ZYPP Installer" [06/Oct/2011:14:52:05 -0700] "GET /x86_64/sled10sp4/updates/media.1/media HTTP/1.1" 200 32 "-" "Novell ZYPP Installer" [06/Oct/2011:14:52:05 -0700] "GET /x86_64/sled10sp4/updates/content HTTP/1.1" 200 1046 "-" "Novell ZYPP Installer"
And now it can see the new/updated stuff. In fact, the zypper refresh kicks out the /content is unsigned stuff, since I never did do that part, as our autoyast stuff just accepts the repos unsigned. When I say yes to accepting the unsigned bits, it then reads the rest of the descr/packages files.
But on SLE11 (SLED11 SP1):
Any zypper refresh checks more files out of the gate, and seems to see new/updated stuff right away: [06/Oct/2011:14:55:20 -0700] "GET /x86_64/sled11sp1/updates/content HTTP/1.1" 200 623 "-" "ZYpp 6.37.0 (curl 7.19.0) sle-11-x86_64" [06/Oct/2011:14:55:20 -0700] "GET /x86_64/sled11sp1/updates/media.1/media HTTP/1.1" 200 31 "-" "ZYpp 6.37.0 (curl 7.19.0) sle-11-x86_64"
None of this is a problem per se, but I was just trying to figure out the official word. I already dropped in a script that automates the create_package_descr step, updates the sha1 sums in the content file and stuff, so adding another step to update that line with a current timestamp for sle10 stuff would be pretty easy. I had previously been annoyed at how zypper list-updates didn't seem to work right on existing hosts when we added updated rpms for sle10 installs, and now I guess I understand why.
As time goes on and sle10 based hosts go away (which will take awhile yet, it takes awhile to get our engineers up the just behind current, let alone current) this whole issue will go away with it too I suppose.
I found http://en.opensuse.org/openSUSE:Standards_YaST2_Repository_Metadata_media which describes the value in there as usually a timestamp, but doesn't say anything about updating it if/when you update the repository.
on Friday 07 October 2011 Mike Marion wrote:
On SLE10 (SLED 10 SP4 specifically):
oh, okay. We are talking about SLE10. I was thinking of SLE11. I talked to our libzypp expert and you are right. On SLE10 we check the media file.
I found http://en.opensuse.org/openSUSE:Standards_YaST2_Repository_Metadata_media which describes the value in there as usually a timestamp, but doesn't say anything about updating it if/when you update the repository.
Right, on SLE10 the value is used as media id: same value == same media(content). The file is quite small and was used as indicator for a changed repo. Meanwhile internet connections are faster, and you don't have to fight for each byte, so on SLE11 we check the repos index file itself. That's why rebuilding the repo is sufficient.
On Fri, Oct 07, 2011 at 11:52:03AM +0200, Uwe Gansert wrote:
Right, on SLE10 the value is used as media id: same value == same media(content). The file is quite small and was used as indicator for a changed repo. Meanwhile internet connections are faster, and you don't have to fight for each byte, so on SLE11 we check the repos index file itself. That's why rebuilding the repo is sufficient.
Thanks, confirms what I've been seeing, but good to hear a more official word.
I'll just have my updater script update the media file on the sle10 repos too.
autoinstall@lists.opensuse.org
-
Cameron Seader -
Mike Marion -
Uwe Gansert