[gentoo-dev] Re: Prevent binary/non-compiled packages from binary package creation

[Duncan <1i5t5.duncan@cox.net>]

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