On 10/28/18 7:33 AM, Konstantin Gizdov wrote:
The `python-uproot` package required `python-uproot-methods` in a new upstream release. This in turn required `python-awkward-array`. Then, `python-awkward-array` listed as requirements (on their page, discussed at length and addressed later in the bug tracker as you pointed out) at the time `numba`, `dask`, `bcolz`, `arrow`. I wanted to provide the update so I had to push/find all these. The problem appeared when I tried to create the python2 version of the relevant ones (as I provide the uproot variant of this). `bcolz` does not have a python2 variant still and at the time neither did `dask`. I asked on the relevant pages for the maintainers to add them. In the meantime, I wanted to still update `python-uproot`. Considering all these were optional, I was able to push a new release. This is why it was rushed and this is why it needs a rewrite - it could not, at the time, be complete because of the constraints. Yes, in principle I could have also tried to provide `python2-bcolz` and `python2-dask`, but I thought the current maintainers will do a better job at this.
My concern is not that I want a rationalization for why you pushed a broken PKGBUILD. You didn't *have* to update python-uproot at all. My concern is why you expect people to vote for you when you still seem to think it's okay to push broken or substandard packages that you didn't put effort into, simply because you want to update another package *now* rather than in a few days once you've had a chance to make sure it is being built on firm ground rather than quicksand. I would prefer slightly older software that works, in preference over hemorrhaging edge software that doesn't work, or only works on the maintainer's machine.
As it was picked up in [community], I have not tried to keep it up to date. I think it was mentioned by you on the bug tracker that `python-awkward` in [community] derives its name from the pypi.org page, rather than the project page (`awkward-array`).
Aside: the PyPI.org page is based on the module name, the project page isn't the interface to the software and is really only relevant in terms of the github url used to access it. So it seems natural to use that...
Thus, I discovered a few weeks back, that the AUR blacklisting was not taking care of it, at least for me. So pushed a small temporary update, thinking since it was mentioned, it was being taken care of and in due time a `provides=('python-awkward-array')` is going to appear in the official binary. I do not presume to know if that's how these things are addressed, but this is why `python-awkward-array` is in this (meta-)state.
No one ever asked for a provides, though. As for adding one, I don't see the point -- the field is meant for cases where e.g. one package is a drop-in replacement for another package, like -git packages, and for the binary repositories we'll keep a provides when renaming a package, but we try to remove those provides, as soon as all official packages have migrated over to the new dependency name. I guess we could provide a conflicts for the python-awkward package, to prevent "error: conflicting files" when an AUR user had the previous name. But there's no package in the official repos which needs the provides.
I am guessing at this stage the correct action from my side is to request deletion of my AUR variant and change `python-uproot-methods` to point to `python-awkward`, but I did want to give it time to see where things are going. Now I see where they are going and will correct it, if you agree with this resolution.
That seems fine, yes.
I think that should give responses to all your concerns (including below), since I couldn't find a nice way to structure it under each of your paragraphs.
Can you please refer me to which community package you refer to? I can state with some authority that nothing has ever changed, and this was never correct. I asked you about this a month ago, but you never responded to me.
I did respond to question:
https://lists.archlinux.org/pipermail/aur-general/2018-September/034290.html
That package has never had a broken/nonexistent build function and missing makedepends, though. So I'm still unsure where you got this incorrect PKGBUILD syntax from.
I'm sorry to hear that. I think I have good reasons (listed above) for the current state of this specific package. My other ones should be better I hope.
I guess I'd hope they're better, but I don't acknowledge any sort of reason as good for an *invalid* PKGBUILD. If it were a matter of a PKGBUILD failing to use https, or having non-unique sources, or failing to quote srcdir/pkgdir, using msg2 which isn't even illegal, just something I personally dislike, or simply using bad bash like: sed ... $(find ...) Then I could say "this is something that could use improvement, I anticipate seeing you do so". The problem I see is in your mindset -- I don't think you approach packaging with due respect for quality. -- Eli Schwartz Bug Wrangler and Trusted User