Mailinglist Archive: opensuse-bugs (7837 mails)

< Previous Next >
[Bug 536495] New: Metalinks for Factory noarch packages may be incorrect
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Thu, 3 Sep 2009 03:43:53 -0600
  • Message-id: <bug-536495-21960@xxxxxxxxxxxxxxxxxxxxxxxx/>

Summary: Metalinks for Factory noarch packages may be incorrect
Classification: openSUSE
Version: unspecified
Platform: Other
OS/Version: Other
Status: NEW
Severity: Blocker
Priority: P5 - None
Component: Download Infrastructure
AssignedTo: poeml@xxxxxxxxxx
ReportedBy: poeml@xxxxxxxxxx
QAContact: adrian@xxxxxxxxxx
CC: adrian@xxxxxxxxxx, coolo@xxxxxxxxxx, mls@xxxxxxxxxx
Found By: ---

Metalinks may be incorrect in Factory for noarch packages, which can cause an
installation or update to stall.

The reason likely is that the build service pushes out noarch packages twice,
and when the second version of the package arrives (with identical filename),
its mtime is older than the mtime of the metalink hash in the metalink cache.
Since metalinks in the cache are regarded valid when newer than the respective
file, a stale metalink is delivered that doesn't match the package in question.

The result is that the client unsuccessfully tries to download the file - if
the mirrors are reasonably up to date, it will seem to the client as if all
mirrors deliver incorrect content, so it keeps trying:

Retrieving package bundle-lang-gnome-en-11.2-16.2.noarch (9/676), 11.4 MiB
(21.1 MiB unpacked)
Retrieving: bundle-lang-gnome-en-11.2-16.2.noarch.rpm [error (39.9 KiB/s)]
Failed to download ./suse/noarch/bundle-lang-gnome-en-11.2-16.2.noarch.rpm from
Abort, retry, ignore? [a/r/i/?] (a): r
Retrieving: bundle-lang-gnome-en-11.2-16.2.noarch.rpm [error (54.3 KiB/s)]
Failed to download ./suse/noarch/bundle-lang-gnome-en-11.2-16.2.noarch.rpm from
Abort, retry, ignore? [a/r/i/?] (a): r

After regenerating the metalink, it works:

Retrieving: bundle-lang-gnome-en-11.2-16.2.noarch.rpm [done (2.5 MiB/s)]
Installing: bundle-lang-gnome-en-11.2-16.2 [done]

Some evidence, which lead to this conclusion, collected below.

The current file:

# l
-rw-r--r-- 1 mirror stage 11930514 2009-09-01 05:30
# md5sum

The metalink hash in the cache:

# l
-rw-r--r-- 1 mirror stage 3872 2009-09-01 13:11

# head
<hash type="md5">b270770c4f344f5344c90ed3beae463e</hash>
<hash type="sha1">fc15aee264bd603d3ca2c36d83a67a90897bc879</hash>
<pieces length="262144" type="sha1">
<hash piece="0">1aa38fdf45599c92e5f9bb8a125a7fd853794598</hash>
<hash piece="1">7008290f044d43509463edc770450db802800d5c</hash>
<hash piece="2">de9d70b33a1d8b9c7daa1333051d1f2917bdedc8</hash>
<hash piece="3">d3a9c33642c6488a9dcfdc15fb10627c24fbc0b7</hash>
<hash piece="4">0602b9e872997aabe849a81e57179b62e36637a3</hash>

Times when different versions of the file arrived:

# ( bzcat /var/log/rsyncd-internal.log-2009090* ; cat
/var/log/rsyncd-internal.log ) | grep
2009/09/01 10:48:42 [708] send
factory/repo/oss/suse/noarch/bundle-lang-gnome-en-11.2-16.2.noarch.rpm 11930628
2009/09/02 16:46:47 [19868] send
factory/repo/oss/suse/noarch/bundle-lang-gnome-en-11.2-16.2.noarch.rpm 11930514

The proposed fix is to change the script that (re-)creates the hashes
(metalink-hasher) to notice modification of files regardless of mtime, which is
probably best done by keeping state of the inode.

The fix would require Apache to be changed as well. (I'm still thinking a bit
about the best route here.)

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >