[PATCH] distgit: Upload files to both the new and old path

Toshio Kuratomi a.badger at gmail.com
Thu Jun 4 14:06:14 UTC 2015


On Jun 4, 2015 5:35 AM, "Mathieu Bridon" <bochecha at fedoraproject.org> wrote:
>
> On Fri, 2015-05-29 at 11:56 -0700, Toshio Kuratomi wrote:
> > On Fri, May 29, 2015 at 12:43:32PM +0200, Mathieu Bridon wrote:
> > > If everybody agrees this is the desired behaviour, can we deploy it
> > > in production?
>
> This had been deployed in production, which took me a bit by surprise
> as this discussion didn't seem to have been finished.
>
> It caused a bit of a stir due to SELinux (it was disabled in staging
> when I tested those changes), but we fixed it with Pierre-Yves:
>
>     https://fedorahosted.org/rel-eng/ticket/6191
>
> > Can we avoid the reupload?  Hopefully it won't hit too many people
> > (because they'll remember when they have a tarball already uploaded)
> > but it can be painful to wait for something to upload again if it's
> > not needed.
>
> The same script handles both:
>
> * checking if a file exists
> * uploading a file
>
> When it's called with the upload, we can't do much in the script to
> avoid a reupload, it's just going to be reuploaded, and as such the
> behaviour I described in my previous email will ensure we end up with
> the two copies linked to each other.
>
> However, we could avoid the reupload in normal cases (i.e "fedpkg
> upload" and "fedpkg new-sources") because pyrpkg always checks if the
> file exists (calling the CGI script) before uploading it.
>
> So we could make the "check" portion of the code verify if the file is
> present either in the old or new location, and if it's found only in
> the old one, symlink it to the new one.
>
> If that makes sense, I'll cook up a patch (and test it with SELinux
> enforcing in staging, this time ;) )
>
Yep, that sounds like a good plan!

-Toshio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20150604/a3c3da18/attachment.html>


More information about the infrastructure mailing list