[aur-requests] [PRQ#2407] Merge Request for ptscotch-openmpi
eleftg [1] filed a request to merge ptscotch-openmpi [2] into scotch [3]: the reasons are explained in a former deletion request that i couldn't find how to cancel... [1] https://aur.archlinux.org/account/eleftg/ [2] https://aur.archlinux.org/pkgbase/ptscotch-openmpi/ [3] https://aur.archlinux.org/pkgbase/scotch/
Request #2407 has been rejected by Muflone [1]: Please settle the merge with the current maintainer @jedbrown Also the packages openfoam* would be broken from this merge. Ask their maintainer to fix the packages first. [1] https://aur.archlinux.org/account/Muflone/
The request was a potential merge of ptscotch-openmpi to scotch. Would the packages openfoam* be really broken? ptscotch-openmpi is provided by scotch (it's in the "provides" list)... I brought up this issue in aur-general a month ago. kragacles (of openfoam) and jedbrown (of ptscotch-openmpi) seemed to agree. On Mon, Mar 2, 2015 at 11:42 AM, <notify@aur.archlinux.org> wrote:
Request #2407 has been rejected by Muflone [1]:
Please settle the merge with the current maintainer @jedbrown Also the packages openfoam* would be broken from this merge. Ask their maintainer to fix the packages first.
Hi
The request was a potential merge of ptscotch-openmpi to scotch.
Would the packages openfoam* be really broken? ptscotch-openmpi is provided by scotch (it's in the "provides" list)...
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.
I brought up this issue in aur-general a month ago. kragacles (of openfoam) and jedbrown (of ptscotch-openmpi) seemed to agree.
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. Regards -- Fabio Castelli aka Muflone
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
Hi again
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
Real names don't help too much to understand the packages ownerships but actually on that thread apart those of yours the only messages were from Gordian Edenhofer and Michele Mocciola and both of them don't seem to me neither Andrew Fischer nor jedbrown. Forgive me but there's no point in that thread that let us think that any of the packagers agree with the merge.
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.
@Andrew Fischer If you want to ease the merge, please update your openfoam package to use the scotch package, obviously after checking that scotch really provides the proper dependencies.
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.
@Jed Brown do you agree in merging (in other words, to delete) the package ptscotch-openmpi into the scotch package? @George Eleftheriou I don't know how scotch works (and please, as maintainer, don't force us to understand the internal dependencies between packages) but I must repeat what I wrote you before: settle with the maintainers this merge and after that file a new merge request 1) Ask to jedbrown to let us know that he will not maintain anymore the ptscotch-openmpi package (or better adopt it yourself) 2) Ask to kragacles to update his package to depend on scotch package (or whatever else you want) instead of ptscotch-openmpi (which will be deleted after this merge). Regards -- Fabio Castelli aka Muflone
I'll update openfoam today and verify it works with this new package. Thanks for keeping me in the loop. -Andrew On Wed, Mar 4, 2015 at 7:37 AM, Muflone <webreg@vbsimple.net> wrote:
Hi again
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
Real names don't help too much to understand the packages ownerships but actually on that thread apart those of yours the only messages were from Gordian Edenhofer and Michele Mocciola and both of them don't seem to me neither Andrew Fischer nor jedbrown.
Forgive me but there's no point in that thread that let us think that any of the packagers agree with the merge.
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.
@Andrew Fischer If you want to ease the merge, please update your openfoam package to use the scotch package, obviously after checking that scotch really provides the proper dependencies.
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.
@Jed Brown do you agree in merging (in other words, to delete) the package ptscotch-openmpi into the scotch package?
@George Eleftheriou I don't know how scotch works (and please, as maintainer, don't force us to understand the internal dependencies between packages) but I must repeat what I wrote you before: settle with the maintainers this merge and after that file a new merge request
1) Ask to jedbrown to let us know that he will not maintain anymore the ptscotch-openmpi package (or better adopt it yourself)
2) Ask to kragacles to update his package to depend on scotch package (or whatever else you want) instead of ptscotch-openmpi (which will be deleted after this merge).
Regards
-- Fabio Castelli aka Muflone
-- Andrew Fischer, PhD Apastron, LLC 903 1st ST N Hopkins, MN 952-373-1024
Muflone <webreg@vbsimple.net> writes:
@Jed Brown do you agree in merging (in other words, to delete) the package ptscotch-openmpi into the scotch package?
Yes, agreed. I also think ptscotch-mpich should be renamed "scotch-mpich" for consistency (and tab completion) with "scotch" (which is an Open MPI build).
@George Eleftheriou I don't know how scotch works (and please, as maintainer, don't force us to understand the internal dependencies between packages) but I must repeat what I wrote you before: settle with the maintainers this merge and after that file a new merge request
1) Ask to jedbrown to let us know that he will not maintain anymore the ptscotch-openmpi package (or better adopt it yourself)
I've disowned it, but it can be deleted now that "scotch" provides it. Thanks, everyone.
All, I've updated OpenFOAM in AUR to using the new merged scotch library. It checks out. Thanks to everyone helping this happen. -Andrew On Wed, Mar 4, 2015 at 6:32 PM, Jed Brown <jed@jedbrown.org> wrote:
Muflone <webreg@vbsimple.net> writes:
@Jed Brown do you agree in merging (in other words, to delete) the package ptscotch-openmpi into the scotch package?
Yes, agreed.
I also think ptscotch-mpich should be renamed "scotch-mpich" for consistency (and tab completion) with "scotch" (which is an Open MPI build).
@George Eleftheriou I don't know how scotch works (and please, as maintainer, don't force us to understand the internal dependencies between packages) but I must repeat what I wrote you before: settle with the maintainers this merge and after that file a new merge request
1) Ask to jedbrown to let us know that he will not maintain anymore the ptscotch-openmpi package (or better adopt it yourself)
I've disowned it, but it can be deleted now that "scotch" provides it.
Thanks, everyone.
-- Andrew Fischer, PhD Apastron, LLC 903 1st ST N Hopkins, MN 952-373-1024
participants (5)
-
Andrew Fischer
-
George Eleftheriou
-
Jed Brown
-
Muflone
-
notify＠aur.archlinux.org