https://bugzilla.redhat.com/show_bug.cgi?id=1758626 --- Comment #24 from Ankur Sinha (FranciscoD) <sanjay.ankur@xxxxxxxxx> --- (In reply to Laurent Rineau from comment #21) > I love to see iso2mesh packaged in Fedora, but there have been error in this > review. Even rpmlint can see them: > > [lrineau@bonnard]~% rpm -q octave-iso2mesh; rpmlint octave-iso2mesh > octave-iso2mesh-1.9.1-1.fc30.x86_64 > octave-iso2mesh.x86_64: E: devel-dependency gmp-devel > octave-iso2mesh.x86_64: W: spelling-error Summary(en_US) volumetric -> > cliometric > octave-iso2mesh.x86_64: W: spelling-error %description -l en_US volumetric > -> cliometric > octave-iso2mesh.x86_64: W: spelling-error %description -l en_US modality -> > morality, mortality > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalmesh > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalpoly > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsimp2 > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsurf > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cork > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/jmeshlib > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/meshfix > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/tetgen1.5 > octave-iso2mesh.x86_64: W: dangerous-command-in-%preun mv > 1 packages and 0 specfiles checked; 9 errors, 4 warnings. > > > Plus: tetgen is already packaged in Fedora. > > Should I fill new bugs for that? > > Qianqian Fang: I am willing to help with those issues, if you agree. This is where bundling gets ugly. :( So, bundling tetgen etc if fine if necessary, but the binaries should not be in /usr/share. That violates the FHS as rpmlint points out. Can they be moved to an arch specific directory, preferably %{_libdir}/isomesh/... (so they remain private and do not clash with the system tetgen libraries + binaries), which will expand to /usr/lib/isomesh/ and /usr/lib64/isomesh according to the architecture of the machine? Please also specify that these are bundled by iso2mesh. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling refers to libraries, so maybe we'll need to speak to the FPC about bundling binaries. Provides: bundled(tetgen) ... (In reply to Qianqian Fang from comment #22) > @Laurent, thanks for chiming in. > > I just tested octave-iso2mesh on f30 in updates-testing repo, the > installation and execution was fine. > > regarding your comments > > 1. the arch-dependent-file-in-usr-share will be triggered as long as the > octave package contains a mex file (like in octave-zmat and octave-mcxlab > that I just created/pushed), or in this case, bundled executables. I > currently don't see other workaround for removing this error; the earlier > two reviewers, Ankur Sinha and Robert-André Mauchin seemed to be ok with > that too. Please see above. > > 2. regarding tetgen, please see Comment 4 and Comment 5 for the discussions. > These are internal tools and are not intend to be called outside of > iso2mesh. I prefer to bundle these tools as much as possible to allow a mesh > reproduced across platforms, and does not reply on the versions of a tool > installed on a user's system (wish I could do the same for cgal, but it is > too big to be bundled internally). Many of my other tools (such as mmc: > http://mcx.space/#mmc) rely on a reproducible mesh to run examples > correctly. Also, bundling this utility is allowed by their respective > licenses. I understand this, but as I did say in my comments---do we have an idea of how sensitive iso2mesh is to tetgen? What is required of tetgen to ensure reproducibility? If tetgen on different platforms yields different results, does that mean that all tools that rely on tetgen are always affected and will always bundle it? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
