Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Prevent binary/non-compiled packages from binary package creation
Date: Thu, 10 Aug 2017 23:31:07
Message-Id: pan$7350e$58332f14$32d1506b$
In Reply to: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation by "William L. Thomson Jr."
1 William L. Thomson Jr. posted on Tue, 08 Aug 2017 12:37:42 -0400 as
2 excerpted:
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.
12 There's actually potentially significant differences and potential
13 benefit. In addition to those already mentioned by others...
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.
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.
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.
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.
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.
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.
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.
52 While it does seem odd, there are certainly benefits in some cases...
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.
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.
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.
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/.
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.
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


Subject Author
Re: [gentoo-dev] Re: Prevent binary/non-compiled packages from binary package creation "William L. Thomson Jr." <wlt-ml@××××××.com>