[aur-requests] [PRQ#4831] Request Accepted
Request #4831 has been accepted by Muflone [1]. [1] https://aur.archlinux.org/account/Muflone/
W dniu 21.02.2016 o 21:34, notify@aur.archlinux.org pisze:
Request #4831 has been accepted by Muflone [1].
Again, this is not a duplicate and the removal is not needed. Here's the story: I used to maintain grass package in the "old" AUR. I didn't have time to maintain it for some time and missed the AUR migration. I was actually happy that someone took over. But I noticed a couple issues in the grass PKGBUILD compared to how it was when I maintained it and wanted them fixed. What Doug called a "cleanup" of my PKGBUILD was mostly (not fully, but mostly) crippling it down, stripping it off relevant (and some irrelevant :)) comments and changing some syntax. I tried to focus on the positives though, and started a discussion about just the mssing bits, in the comments on the grass AUR page few months ago. Doug was strangely hesistant to fix some of the issues, for no reason, and for no benefit to anyone. He treated me like an intruder, jumped on me, (quote: "You abandoned the package. Deal with it".) and decided I was "badgering and pestering". It annoyed me, I replied accordingly and gave up on him. When some time passed, he eventualy implemented most of the bits he previously removed during his "cleanup" (some being hacks, but unavoidable), possibly partly due to other users's comments, but he didn't miss an opportunity to call GRASS developers "lunatics" in regard to Python 2/3 issue. How nice. Thing is that GRASS is not ready for Python 3 as "the python" at its build- and run-time, there's nothing wrong or right about it. This is just how it is. Any approach to this issue is a kind of a hack for now, and the simpler and less intrusive the hack - the better IMO. So when I maintained the GRASS PKGBUILD, I used a python2 symlink instead of patching the sources using sed, which is more effort and can be error-prone. One of the things still missing in Doug's grass PKGBUILD is liblas dependency. Back in October he just explicitely refused enabling it without any explanation, and apparently hasn't changed his mind since. This means disabling LIDAR functionality in GRASS, which is pointless and a major drawback. So I uploaded another GRASS 7 PKGBUILD (as "grass7") with liblas dependency enabled (plus enabling OpenMP, LAPACK and BLAS features, going a safe route with wxPython 2.8 vs 3 and using a python2 symlink at buildtime instead of massaging the sources with sed). Then Doug requested grass7 removal, making judgement calls about what qualifies an AUR package, but unwilling to include the missing bits in his package when being asked for it in past. Kindoff catch 22. I'm trying to appreciate his contribution. But I don't understand his motives and chaotic reactions, I perceive his behavior hostile. Based on the very unpleasent past experience I don't I want to have to try convincing him to do this or that. I'd rather avoid getting involved with him regarding liblas dependency and in future grass PKGBUILD maintenance. But I still want to provide a feature-rich, high quality GRASS 7 package for Arch. So, please let me know what package name I should use instead of "grass7", and I will gladly play along.
On Mon, 22 Feb 2016 at 02:46:56, Maciej Sieczka wrote:
W dniu 21.02.2016 o 21:34, notify@aur.archlinux.org pisze: [...] When some time passed, he eventualy implemented most of the bits he previously removed during his "cleanup" (some being hacks, but unavoidable), possibly partly due to other users's comments, but he didn't miss an opportunity to call GRASS developers "lunatics" in regard to Python 2/3 issue. How nice. Thing is that GRASS is not ready for Python 3 as "the python" at its build- and run-time, there's nothing wrong or right about it. This is just how it is. Any approach to this issue is a kind of a hack for now, and the simpler and less intrusive the hack - the better IMO. So when I maintained the GRASS PKGBUILD, I used a python2 symlink instead of patching the sources using sed, which is more effort and can be error-prone.
Maybe you misunderstood Doug here: There is nothing wrong with only supporting Python 2 for the time being but it is wrong to specify an unversioned shebang if you do. Patching the source code to use the right Python version really isn't much more effort (3 lines vs. 2 lines) and it is the standard way of fixing this kind of issues in the official repositories. It would be even better to report this upstream and tell them to use the correct headers according to PEP 394.
One of the things still missing in Doug's grass PKGBUILD is liblas dependency. Back in October he just explicitely refused enabling it without any explanation, and apparently hasn't changed his mind since. This means disabling LIDAR functionality in GRASS, which is pointless and a major drawback.
So I uploaded another GRASS 7 PKGBUILD (as "grass7") with liblas dependency enabled (plus enabling OpenMP, LAPACK and BLAS features, going a safe route with wxPython 2.8 vs 3 and using a python2 symlink at buildtime instead of massaging the sources with sed). Then Doug requested grass7 removal, making judgement calls about what qualifies an AUR package, but unwilling to include the missing bits in his package when being asked for it in past. Kindoff catch 22.
I'm trying to appreciate his contribution. But I don't understand his motives and chaotic reactions, I perceive his behavior hostile. Based on the very unpleasent past experience I don't I want to have to try convincing him to do this or that. I'd rather avoid getting involved with him regarding liblas dependency and in future grass PKGBUILD maintenance. But I still want to provide a feature-rich, high quality GRASS 7 package for Arch.
So, please let me know what package name I should use instead of "grass7", and I will gladly play along.
I do not known enough about GRASS to decide whether having this feature enabled is a must-have. However, it's usually up to the maintainer to decide which features are enabled by default. If you want different features, just change the PKGBUILD before building (since we're using Git for AUR packages, you can even put those changes on a separate branch and merge them on every update). Given that GRASS does not seem to be too popular, it probably doesn't make sense to upload another package just to change the set of features enabled by default. Regards, Lukas
participants (3)
-
Lukas Fleischer
-
Maciej Sieczka
-
notify＠aur.archlinux.org