Hi,
thanks for your reply. This kind of issue doesn't come up with
incomplete rsyncs. The package files weren't corrupt, invalid or only
partially available (which might be the case when using inplace rsyncs).
The thing is that at some point (a) before the 19th of june these
packages existed in your repository:
(1) osm2pgrouting_10-2.3.3-1.rhel7.x86_64.rpm
(2) osm2pgrouting_10-debuginfo-2.3.3-1.rhel7.x86_64.rpm
with a checksum of C(a), a filesize of S(a), a gpg signature of G(a) (or
no signature at all) and a built date of B(a).
Now eventually (b) around the 19th of june the existing packages were
overwritten with packages of the *same name* but with a different
checksum and either
- a different filesize S(b) != S(a) and/or
- a different gpg signature G(b) != G(a) and/or
- a different built date B(b) != B(a)
(for details see my previous email).
These packages changed between the 28th and the 29th of june:
(3) pgadmin4-python-pbr-3.1.1-1.rhel7.noarch.rpm
(4) pgadmin4-python-simplejson-3.13.2-1.rhel7.x86_64.rpm
(5) pgadmin4-python-simplejson-debuginfo-3.13.2-1.rhel7.x86_64.rpm
(6) pgadmin4-python-sshtunnel-0.1.3-1.rhel7.noarch.rpm
in the same way as above.
Yum/dnf has two caches. One is the /var/cache/{dnf,yum} directory, which
can be cleared easily when dealing with such repositories, the other one
is the http_caching which needs to be dis- and re-enabled to resolve
that kind of issues. But unattended updates or downloads won't do this
automatically and will require manual intervention.
Let's assume you're mirroring a repository using the yum-utils' provided
'reposync'. This utility, which relies on yum's libraries, has a simple
but widespread mechanismn for downloading files: if a file already
exists locally, it tries to download it using a "Range:"-header in order
to resume possibly aborted downloads. So when the remote package is
bigger than the existing one – which is the case for (3) – it appends
the differing four bytes to the existing file, corrupting it (same for
e.g. wget -c et al). On the other hand, if the remote file is smaller
than the local file, a "Range:"-request results in a "416 range not
satisfiable".
Please examine the attached files if there's still something unclear:
> rpm -qp --qf '%{name}-%{version}-%{release}: %{buildtime:date}; %{siggpg:pgpsig}\n' *.rpm.{old,new}
> stat -c '%n %s' *.rpm.{old,new}
> md5sum *.rpm.{old,new}
Best,
Philippe