Some ebuilds, such as dev-util/pycharm-community, don't actually download and compile source code for the packages, but just install a precompiled binary. There is no way to identify and eliminate these packages. There are a number of severe problems with this situation: * It is logical to assume that when emerging any libre package, the source code would be downloaded and compiled. * By extension of that assumption, when allowing only libre licenses in make.conf, no software in binary form should ever be downloaded, much less installed. * Without the source code, packages cannot be patched or maintained by the user. * If packages are installed as binaries, there is no guarantee that they are actually able to be compiled and installed using only libre software. Having proprietary build-time dependencies eliminates some of the essential freedoms theoretically afforded by using libre software. * I want local copies of the source code of ALL software I am running at any given time. With the current Portage tree, there is no way to enforce that in my make.conf policies. In summary, there should be a way to prevent precompiled files from ever being downloaded or installed by Portage. As listed above, this limitation destroys several of my reasons for my choosing a supposedly source-based distribution, rendering the Portage tree severely broken for my use. Reproducible: Always Steps to Reproduce: 1. Attempt to configure Portage to ensure that local copies of all source code for the system are available. 2. Emerge dev-util/pycharm-community. Actual Results: A precompiled binary of PyCharm is downloaded and installed. Expected Results: Either: Source code for PyCharm is downloaded, compiled, and installed or: Give an error indicating that PyCharm is unable to be compiled from source using only libre software, despite it being "libre" software itself. I feel like maybe I rant a bit too much in this bug report.
I am not aware of any existing Gentoo packaging policy requiring that ebuilds must compile things from source code. Sometimes it just isn't practical. Being able to more easily identify "binary" ebuilds seems like a nice idea, but bugzilla is not the discussion forum for it. There was a recent discussion thread on the gentoo-dev mailing list where you might voice your concerns or help come up with a solution.
The clarify: if you can come up with some specific changes that would improve things, we can route enhancement requests to the Portage or PMS maintainers. But a generic rant about binary ebuilds is not actionable.
The mailing list discussion on this issue is at https://archives.gentoo.org/gentoo-dev/message/ecc121d7e1e74cb108034296fcf44818 In that thread, solutions of adding a metadata entry, or requiring packages to be named with -bin were suggested. In IRC, it was suggested to implement this by adding a value to RESTRICT; in my opinion that is the best solution.
In response to further discussion on IRC, it seems I should send that summary of proposed solutions to the mailing list, to develop consensus on a single one on which to file a bug. Thanks!
