https://bugzilla.redhat.com/show_bug.cgi?id=1367526 Paulo Andrade <paulo.cesar.pereira.de.andrade@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: brial - |Review Request: brial - |BRiAl is the successor to |Framework for Boolean Rings |PolyBoRi | --- Comment #5 from Paulo Andrade <paulo.cesar.pereira.de.andrade@xxxxxxxxx> --- (In reply to Jerry James from comment #4) > A few more fixes to make, all small. See below. > > (In reply to Paulo Andrade from comment #3) > > Ok. Added the proper Obsoletes/Provides. Only sagemath uses it, so, > > once a sagemath 7.3 package is available, polybori can be retired. > > I see Obsoletes/Provides for the -devel package, but not for the main > package, nor for the python package. Shouldn't those Obsolete/Provide their > polybori equivalents, too? Only brial-devel conflicts with polybori-devel, so at first I preferred to not create an artificial conflict, as runtimes can be installed at the same time. But I can add it, as one doing "serious" work depending on polybori (and not using brial) is likely not using the system package. > > Thanks. Changed to use the suggested pattern, that indeed corrects the > > problem. On not yet released versions it should actually make use of gd > > and png. > > The current code base only uses gd if m4ri has not been built with png > support (and the Fedora version does have such support). Are you saying > that the next version will use gd anyway? I was going to ask upstream, but it was already asked :( https://github.com/BRiAl/BRiAl/issues/6 > > I believe this is more of something to ask upstream, it explicitly requires > > python 2.7: > > AM_PATH_PYTHON([2.7]) > > so, I believe this is a work in progress by upstream. > > Okay. It would be nice to provide the python 3 version when it is available. Ok. The code is there, so upstream is more of in a waiting for contributions as well. Something to do, but likely, upstream sagemath is who has more resources for it. > > I used the sagemath SPKG.txt text, but indeed it was not looking right. > > Now it was changed the Summary to the same as polybori, and description > > basically s/PolyBori/BRiAl/. > > Note that the very last sentence of %description still uses the word > PolyBoRi. Thanks! Fixed. > Also, the bug title needs to match the %summary line before you request > package creation. Also fixed. > There is no changelog entry in the spec file for your latest version. Ops, sorry, fixed. > Summary of changes to be made: > 1. Obsoletes/provides for all packages, or a reason why that isn't needed. > 2. Change one more instance of "PolyBoRi" in %description. > 3. Add a changelog entry to the spec file for version 0.8.5-2. > 4. Update the bug title with the current %summary in the spec file. I can make a new srpm with Obsoletes/Provides for the "non conflicting" polybori packages, as otherwise they may sit without use on a system being updated from a previous sagemath version, but should it also Obsoletes/Provides the other polybori packages that brial does not (yet) have an alternative? Those are polybori-gui polybori-docs polybori-static # on purpose there is no alternative polybori-ipbori Spec URL: https://pcpa.fedorapeople.org/brial.spec SRPM URL: https://pcpa.fedorapeople.org/brial-0.8.5-3.fc26.src.rpm -- 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 https://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx