[aur-general] TU Application - Konstantin Gizdov

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181028/162d7e75/attachment-0001.asc>