Without this, the file could exist at both the old and new path, taking
the space on the disk twice.
This forces a hardlink if the file already existed at the old path.
Currently, the CGI script is set to upload files:
- to the old path if the upload uses md5
- to the new path if the upload uses sha512
The old path is as follows:
/%(srpmname)s/%(filename)s/%(hash)s/%(filename)s
The new path is:
/%(srpmname)s/%(filename)s/%(hashtype)s/%(hash)s/%(filename)s
This was meant to ensure compatibility with current fedpkg which
always downloads from the old path, but will eventually download from
the new path when we move to sha512.
However, working more on this, I now think it would make for a smoother
transition if we instead always stored the files at the new path, but
just hardlinked to the old path if the upload is using md5.
This is what this patch achieves.
With this deployed in production, fedpkg could be patched to try
downloading from the new path, and fallback to the old one if necessary,
which decouples the migration to the new path from the migration to the
new hash.
With this change, the upload CGI script will start preferring uploads
hashed as sha512, but still accept md5 as a fallback.
The message emitted on fedmsg is unchanged, because doing so would break
it. We're going to fix that later though.
https://fedorahosted.org/rel-eng/ticket/5846
... as much as possible.
The point of this patch is to make it easier to move away from md5 in a
subsequent patch, without having one monster change which would be
impossible to review.
Some md5 stuff remains hardcoded, because changing it at this point
would break compatibility.
https://fedorahosted.org/rel-eng/ticket/5846
This will make it easier to move away from md5 for the source tarballs.
It shouldn't cause any problem anyway, as Fedora runs this on EL 6 in
production, and EL 7 in staging.
