On Wed, May 25, 2016 at 12:44 PM, Tomas Orsava <torsava@xxxxxxxxxx> wrote: > So, upstream does indeed provide a URL redirector so we can use a predictable URL scheme without hashes. The new URL scheme is: > > https://files.pythonhosted.org/packages/source/p/positional/positional-1.1.0.tar.gz > > Upstream also plans to support the redirector for the long term [0], so I believe switching to it in all the spec files our best move. This has, of course, broken every python module "Source" URL in every .spec file in Fedora, RHEL, CentOS, Oracle Linux, Scientific Linux, RPMforge, and many third party repositories. It's also broken "py2pack" in every Fedora release. You can see my comments in the upstream thread: The "redirector" is workable, but I still believe the decision to embed hash entries in the URL's for source code was a horrible, horrible way to deal with people uploading identically named tarballs on top of old tarballs in the PyPi source repositories. > Maybe it would be beneficial to also work the change into the RPM rebase-helper [1] which does automatic scratch builds when a new version of software is detected upstream? Does anyone have experience with this project? > > [0] https://bitbucket.org/pypa/pypi/issues/438/backwards-compatible-un-hashed-package#comment-27734791 > [1] https://github.com/phracek/rebase-helper Updating spec files dynamically this way is a horrbile approach. If there is a python widget to simply report the URL of the upstream tarall, and not actually *collect* the tarall the way py2pack does, great. But it doesn't fix the underlying problem. Authors are uploading identically named tarballs on top of each other, so if you query such a tool on one day, you will get a different URL and different tarball than if you query such a tool on the next day. CPAN and maven and gradle and other build systems pretty much deal with this by using "write once" repositories, and not generally permitting overwrites of published tarballs. So does RPM itself, at least for published repositories. But I'm afraid that PyPi fell prey to the "let'ssolve the problem I want to solve and ignore the problems it creates" approach. > packaging mailing list > packaging@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
