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