Mailinglist Archive: opensuse-bugs (15774 mails)

< Previous Next >
[Bug 245428] Update breaks while drpmsync is running
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 8 Aug 2007 04:58:47 -0600 (MDT)
  • Message-id: <20070808105848.06889245350@xxxxxxxxxxxxxxxxxxxxxx>

--- Comment #9 from Peter Poeml <poeml@xxxxxxxxxx>  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, and rsync with the --delete-after.
I believe that we do it this way for 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 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:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >