William L. Thomson Jr. posted on Tue, 08 Aug 2017 12:37:42 -0400 as excerpted:
> I make a lot of binaries for use on other systems, to expedite updates. > It does not make sense for some packages to ever be a binary package. > > Packages like -bin packages or gentoo-sources, which are just sources. > Having binary ebuilds of those is of no benefit. I can be the opposite > causing things to be much slower. Like in the case of large things > packages like android-studio. There's actually potentially significant differences and potential benefit. In addition to those already mentioned by others... * Binpkgs packages store the build environment as well. This includes eclass functions, etc, which are used from the binpkg, not from the existing tree, which may differ from that used at package creation. For example, some time ago I upgraded glibc (on ~arch) and had to roll back. Downgrading glibc is normally prohibited due to other dependencies that may have been built since that could now depend on the newer glibc, but fortunately I caught the problem quickly and only a handful of packages had been rebuilt after that, and the problem was bad enough that rebuilding the few if necessary was trivial compared to dealing with the broken glibc functionality. Fine, I thought, just emerge the old binpg. Not so easy because it refused to downgrade unless I_KNOW_WHAT_I_AM_DOING was set, and setting that was useless because it wasn't in the binpkg environment. So I ended up doing a full rebuild to get it in the binpkg environment. IIRC I had to do it from a backup, however, because glibc was broken enough I couldn't do it from the working copy, that being the reason I caught it so fast in the first place. Now I keep that variable set for glibc via package.environment, so it's always in my glibc binpkgs in case I need to downgrade and I won't have to do a full rebuild of the old version next time. Obviously glibc's not a pre-built binary, but the same thing could apply there. A variable could be set only on the pkghost, that would apply to all installs of that binpkg due to the saved environment, that wouldn't apply to a non-binpkg merge of the same ebuild. IOW, installing from a binpkg and from the existing tree ebuild could result in differences in the installed package, due only to the environment-saving. > Just seems odd to make a binary of a binary, or repackage gentoo-sources > into a gentoo ebuild binary/binpkg. There is not really any benefit > either way for such packages. While it does seem odd, there are certainly benefits in some cases... > It would be beneficial if ebuilds could have some internal variable that > prevents it from being a binary package. It should not prevent merge or > fail. Just never create a binary of this package, always use the ebuild > as normal. Even if someone is force installing using binary flag or > otherwise. Having an internal binary-prebuild variable set could indeed be useful, but agreed with the others, acting on it should be an option or perhaps an optional FEATURE, controllable by the sysadmin/user, not mandatory. FWIW, I'll almost certainly keep building binpkgs on here, regardless, because among other things I've found it just too useful to be able to go back and see what that older version I have archived looked like, both in terms of the files included, and the saved ebuild and eclass code. I can't count the times I've found it useful to have those old binpkgs for reference, and in fact, that's one of major benefits of using FEATURES=buildpkg in the first place, regardless of the package, in my book. Meanwhile, having buildpkg on virtual packages[1] is what amuses me. There, most of the benefits of binpkgs that arguably apply even to prebuilt binary and no-bin packages as long as they package and install /some/ file, arguably don't apply at all, tho I suppose there might be corner cases where they /could/. --- [1] Virtual packages: Including my own occasional null-pkg. Like sys-fs/udisks, for instance. It's a runtime-only dep of kde-frameworks/solid, used for functionality I don't want/need anyway, so I null-pkg it with an overlay version that has no deps and installs no files. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
