[aur-requests] [PRQ#2407] Request Rejected

[George Eleftheriou]

> in such case it wouldn't be "broken" but as far I remember the AUR
> helpers cannot find the right dependencies based on provides .
> Therefore the package openfoam wouldn't be BROKEN but during the install
> phase it **should** claim about some unsolved dependencies and will
> refuse to build.

Yes, indeed.

> Maybe I missed (and I cannot find in the archives) the aur-general
> discussion where the maintainers would abandon their packages in favour
> of yours, agreeing to the merge, so please send us a link where I can
> see the whole discussion.

https://lists.archlinux.org/pipermail/aur-general/2015-February/030300.html
https://lists.archlinux.org/pipermail/aur-general/2015-February/030301.html
https://lists.archlinux.org/pipermail/aur-general/2015-February/030303.html
https://lists.archlinux.org/pipermail/aur-general/2015-February/030309.html
https://lists.archlinux.org/pipermail/aur-general/2015-February/030310.html

There were two more replies though, which (due to reasons that are
beyond my understanding) were not archived. Either their authors or
other recipients can confirm:

====================================

1) Andrew Fischer:
I'm not a scotch packager so Ill let others comment on the gory
details. But from the openfoam standpoint this sounds like a great
idea. I would definitely be onboard.

2) Jed Brown:
> You are right :-) ( i hadn't yet discovered the real power of "provides")

Seems you got a little overzealous because your package is providing
both ptscotch-mpich2 (a package that doesn't exist) and
ptscotch-openmpi.  MPICH is binary-incompatible with OpenMPI, so these
packages can never be merged.  I would be happy if someone took over
maintainership of ptscotch-{openmpi,mpich}, but ptscotch-mpich (maybe
now called scotch-mpich) should continue to exist and be kept
consistent.  Is that something you're willing to do?

Any reason you're dropping support for arch=i686?  Probably all
architectures should be supported.

====================================

-- I skipped commenting on the architecture point and ptscotch-mpich2
because these two had already been fixed by then.

-- following a separate communication with Jed Brown resulting from a
Deletion Request I filed against ptscotch-mpich (which later regretted
but couldn't cancel it)...

https://lists.archlinux.org/pipermail/aur-requests/2015-February/004963.html
https://lists.archlinux.org/pipermail/aur-requests/2015-February/004968.html
https://lists.archlinux.org/pipermail/aur-requests/2015-February/004976.html

... I offered to take over ptscotch-mpich. Jed didn't answer and
ptscotch-mpich was finally removed but I resubmitted it instantly (an
improved version of the PKGBUILD I had proposed to Jed).

Anyway, the way I see it, is that there is only two *scotch* packages
really needed in AUR in order to cover any scenario. The all-inclusive
scotch and ptscotch-mpich... and what's even better is that they don't
conflict (as the mpich implementation is stored in /opt). Right now,
and for the (foreseeable) future I'll be maintaining both with great
care.

Best regards,
George