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