[aur-requests] [PRQ#4831] Request Accepted

[Lukas Fleischer]

On Mon, 22 Feb 2016 at 02:46:56, Maciej Sieczka wrote:
> W dniu 21.02.2016 o 21:34, notify at 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