Gavin Howard’s bc is known to be a superior and well-maintained implementation. It is now also battle-tested on a number of distros, so I’m wondering if it’s time Fedora/RHEL made the switch. Reproducible: Always
I can give you the package , if you want do th switch to Gavin Howard’s bc
Thank you for the reply. Yes, I’m happy to help do the switch and maintain the package for Fedora. I’ve packaged and tested Howard’s bc locally.
(In reply to Petasus Ruber from comment #2) > Thank you for the reply. Yes, I’m happy to help do the switch and maintain > the package for Fedora. > > I’ve packaged and tested Howard’s bc locally. Hi, are you Fedora packager ? if yes what is you fas username ?
(In reply to Sergio Basto from comment #3) > > Hi, are you Fedora packager ? if yes what is you fas username ? Not yet. My username is petasus. I learnt from this page (https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#comaintainer) that to be able to maintain the package, I need first to be mentored by you as a co-maintainer and have a sponsor ticket opened on my behalf at pagure by the current owner. Is that correct?
Hi, Sorry not reply earlier , yes is correct , but I'm not a packager sponsor, so I can sponsor you to join to the packager maintainers. BTW bc-1.08.1 is available [1] , do you still think it would be better switching to howard-bc ? Switching source would give a lot of work ? or they are similar programs and compile in the same way ? Anyway, you can add pull requests in https://src.fedoraproject.org/rpms/bc with your suggestions . Thank you [1] https://bugzilla.redhat.com/show_bug.cgi?id=2335123
Thank you for taking the time to move this forward. I appreciate it. A pull request has been opened [1]. Howard’s bc can be used as a drop-in replacement for GNU bc. It has the following improvements over GNU bc: - It has more extensions, which make it more useful for scripting. (See [2].) - It is a bit more POSIX compliant. - It has a much less buggy parser. The GNU bc will give parse errors for what is actually valid bc code, or should be. For example, putting an else on a new line after a brace can cause GNU bc to give a parse error. - It has fewer crashes. - GNU bc calculates the wrong number of significant digits for length(x). - GNU bc will sometimes print numbers incorrectly. For example, when running it on the file tests/bc/power.txt in this repo, GNU bc gets all the right answers, but it fails to wrap the numbers at the proper place when outputting to a file. - It is faster. (See [3].) [1] https://src.fedoraproject.org/rpms/bc/pull-request/6 [2] https://git.gavinhoward.com/gavin/bc#extensions [3] https://git.gavinhoward.com/gavin/bc#performance
I see a number of distributions package Gavin's `bc` as `bc-gh`: https://repology.org/project/bc-gh/versions Maybe it would make more sense to create a new package with `bc-gh` name and add "Conflicts: bc" to it. If in the future `bc-gh` is the main used implementation it always can have `Provide: bc`.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
I added @ssmoogen as maintainer of this package . quoting what Stephen Smoogen wrote on devel mailing list : "Moving from one bc to another isn't as easy as the requester may think. There are a lot of sysadmin scripts which use bc in all kinds of places and if they are using the math additions, it can break anything from a school computer accounting system (*cough*) to other things. I would say that the person should look at packaging up the other bc as an alternative but stay with what is there for basic installs." It makes sense to me, first have the two bc's available and gradually replace bc with bc-gh if it is better
Yes, /etc/alternatives remains my preferred solution, and will form the basis of my change proposal. dcantrell also wrote previously: ‘For a change like this, FESCo would generally want to see a change proposed that introduces a new package with the new program such that both it and the existing package can be installed at the same time. Since these packages both provide core command line tool components, setting them up to use /etc/alternatives in order for an end user to set a system default would be necessary to assess how the new package impacts the whole system. A change proposal also needs to include an appropriate test plan and how to communicate the change to users and other package maintainers (especially those directly impacted by a potential 'bc' change).’
Closing this one as first `bc-gh` should be available for Fedora and further discussion after.