William L. Thomson Jr. posted on Tue, 08 Aug 2017 12:37:42 -0400 as
> 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
> 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
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
Meanwhile, having buildpkg on virtual packages 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/.
 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
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