https://bugzilla.novell.com/show_bug.cgi?id=245428#c9 --- Comment #9 from Peter Poeml <poeml@novell.com> 2007-08-08 04:58:46 MST ---
I'd actually propose to close it INVALID or WONTFIX, because there doesn't seem to be a nice way to handle that kind of changes in a repository while installing.
Please let's fix it somehow. The bug is neither invalid, nor should it stay unfixed, if possible, IMO. Offering an option to start over (refreshing metadata) could be all which is needed. IF the drpmsync source is currently being changed with drpmsync however, I suspect that metadata won't be up-to-date anyway. This is an issue with the installation source then, where a refresh in the client will NOT help, because drpmsync causes an inconsistent state in the installation source. This scenario is the reason why we SHOULD use atomic replacement of the installation source (consistent Factory tree synced out to download.opensuse.org), and rsync with the --delete-after. I believe that we do it this way for download.opensuse.org and our mirrors (where we feed them). (Adrian, do we?) I wonder which kind of installation source was used here, and how it could become inconsistent with drpmsync, and I presume that it wasn't download.opensuse.org. Is that right, JP?
Adding Peter to CC, as he might have some input as well, given his recent involvement with the openSUSE download redirector. IIUC, by using the redirector this bug should be way less a problem, because the redirector would redirect you to a mirror (on a file by file basis), that actually has the file. (Even if it already got updated on the main server or servers that we push to.)
The redirector doesn't issue redirects for files that don't exist (on its own filesystem). Using the redirector should fix the issue nevertheless, because the installation source it hosts is not updated in realtime with drpmsync. (Which is the root of the problem.) Even with atomic replacement of the installation source, such a replacement could happen while yast is busy for a while with calculating dependencies, or downloading packages. Thus, it should be fixed to handle this scenario gracefully nevertheless. Allowing the redirector to serve non-existing files (by redirecting to mirrors which might still have them) is not a cure that we count on -- there might be no mirror which has the file. Especially with short-lived Factory sources, this can happen. (I saw this in the past.) Thus, the graceful error handling is required anyway. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.