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

[Maciej Sieczka]

W dniu 22.02.2016 o 15:08, Lukas Fleischer pisze:
> 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.

I did not misunderstand anything. He's calling decent people names in
public, he's not doing things right and doesn't want to do them right.
And everyone has to deal with it, until he changes his mind, which may
or may not happen, because he says so.

> 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.

Fine. But in spite of the patching you still need to add the python2
symlink in a GRASS installation in order to be able to install Python
addons (using g.extension module). I assumed that since the symlink was
required, the patching could be spared.

Anyway, I used to create that python2 symlink in my PKGBUILD, he removed
it not knowing what he was doing and refused to bring it back.
Finally he did that later when somebody complained about addons not
working. And so the story goes. What a waste of time and eneregy, just
because a person won't listen. I would be glad that somoene's trying to
help me improve my code. For him it's badgering and pestering.

> It would be even better to report this upstream and tell them to use
>  the correct headers according to PEP 394.

I'll ask GRASS devs about 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.

You are missing the point. It's not about me. It's about all Arch GRASS
users and about doing things right. Yes, everyone can edit a PKGBUILD,
add a configure switch or something (assuming they know what it should
be) and spend extra time to rebuild the package. But why deliberately
make things harder for everyone like this? LIDAR support is a standard
GIS feature. I know about GIS, GRASS and I know what I'm saying.

Again, he crippled my PKGBUILD down (breaking addons support and
disabling several crucial features) and I had to ask him whether he
could fix this or that. He decided to fix some but not all - eg. the
LIDAR support. He refused just because he could. I don't get it. And
when I'm trying to do things right on my own he stands in my way just
because he can, demanding my contribution go down the drain, just
because he can.

But OK, I tried. I'm not going to argue another person. Sure you can
have it your way if you wish so. GRASS Arch users will have to accept
this incovience.