In my opinion the binary package for xmrig should be dropped. Here are my reasons: 1. XMRig is a "CPU/GPU miner" software. It means that it is designed to put the processor under heavy stress. For my i5-1135g7 laptop it emerged in this time: real 1m13.972s user 6m17.405s sys 0m33.092s I think the package does not take long to compile. 2. Package optimizations Compiling the package provides users to compile with -march=native and other optimizations which will improve performance. Because the fact that XMRig is a miner, it is a critical matter. 3. Microarchitecture version Right now the binhost offers the package for x86_64-v1, which means that it will not use the more efficient instructions the CPU supports. Having the v3 binary would make more sense here (but still not enough IMO) To conclude, dropping the package from the binhost, besides simplifying maintaining it, would push users in the right direction -- having a more performant miner.
xmrig does not appear in binhost.git, so if it does get built, it's either: a) a dependency of something else, or b) chosen by the "lucky" builders which choose random packages on each run Not really sure it makes sense to file a bug for this anyway. Only if something is in binhost.git and there's a very good reason to drop it would we bother.
Right, IMO the correct solution to this would be bug 463964 and expecting users to make that decision for themselves. The other possibility is defining the ebuild as RESTRICT=bindist on the theory that it should "never" be built as a binary package and distributed to other machines. This is usually supposed to be used for packages with license restrictions...
