On Jun 4, 2015 5:35 AM, "Mathieu Bridon" <firstname.lastname@example.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:
> > 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!