On Wed, 22 Apr 2020 at 23:44, Sandro Tosi <mo...@debian.org> wrote: > Andrej, > can you please clarify why you're keep using pristine-lfs even when > prompted not to? this is just from 2 packages uploaded in the last > hour (ftr, pyopenssl is broken now..)
Sandro, wasn’t it all about pristine-tar missing? You (and others) use pristine-tar, you need pristine-tar data. I don’t like it and don’t use it, but okay, I don’t want you to get annoyed by the inability to follow your workflow, I try and use pristine-tar every time. But what’s wrong with also publishing a pristine-lfs branch? It doesn’t prevent you in any way from doing things the way you were doing before. I will look at what happened with pyopenssl. > https://salsa.debian.org/python-team/modules/pyopenssl/-/tree/pristine-lfs > https://salsa.debian.org/python-team/modules/urwid/-/tree/pristine-lfs > On Sat, Mar 21, 2020 at 3:31 PM Scott Kitterman <deb...@kitterman.com> wrote: > > The way to get the policy changed is not to ignore it and then get > > aggressive > > when called on it. Scott, I didn’t get aggressive, or, at least, it was not my intention. I’m sorry if it came across as such. I genuinely believe that pristine-tar should be gradually moved away from to something better, as I had a misfortune to work with it on a large scale (hundreds of packages) and I know how unreliable it sometimes is. Not only it routinely generated tarballs with different checksums, it sometimes failed to generate anything at all. I developed pristine-lfs as a proper tool with the UI compatible with pristine-tar (instead of just a custom script) specifically to help others use it without changing workflows much. -- Cheers, Andrej