Gentoo Archives: gentoo-portage-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-portage-dev@l.g.o
Subject: [gentoo-portage-dev] Re: [PATCH] grabfile_package: support -* in profile "packages" files (bug 610670)
Date: Fri, 24 Feb 2017 02:28:53
Message-Id: pan$b3c8e$8f4ffe01$416e0ea0$a71f3db7@cox.net
In Reply to: Re: [gentoo-portage-dev] [PATCH] grabfile_package: support -* in profile "packages" files (bug 610670) by Brian Dolbec
1 Brian Dolbec posted on Thu, 23 Feb 2017 07:52:15 -0800 as excerpted:
2
3 > On Thu, 23 Feb 2017 11:53:15 +0000 Joakim Tjernlund
4 > <Joakim.Tjernlund@××××××××.com> wrote:
5 >
6 >> On Thu, 2017-02-23 at 02:52 -0800, Zac Medico wrote:
7 >> > Support -* in order to make it easier to create profiles for minimal
8 >> > systems (especially those built entirely from binary packages).
9 >>
10 >> Would be nice, but I don't get what the "packages" file is?
11 >
12 >
13 > That would be the 'packages' file (list of required packages)that are
14 > required for that specific profile. This patch would allow to override
15 > that packages file to build an image that only contained the minimum
16 > runtime pkgs required to perform the tasks it is suppose to. The idea
17 > being you would not need gcc, automake, ... or even portage or possibly
18 > python. The built image could of course be considered more secure not
19 > having a compiler, etc... not to mention smaller.
20 >
21 >
22 > Zac, looks fine to me.
23
24 If my understanding is correct, that this lets me get rid of the whole
25 list of specific system-package negations in
26 /etc/portage/profile/packages and replace it with a single -*, in ordered
27 to eliminate @system entirely, I'm all for it! =:^)
28
29 (I've been running both USE="-* ..." and an entirely negated and thus
30 empty @system set, relying entirely on my own activated USE flags and
31 world_sets list for years now, and this will make it easier both because
32 I won't have that whole @system list to negate individual package atom by
33 individual package atom, and because I won't have to worry any longer
34 about default @system set package atoms changing, thus nullifying my
35 negation and adding them back into my @system set without my knowledge
36 and forcing me to trace down what changed and renegate that package with
37 the new atom, as happened not long ago. Tho I'm not doing it to be
38 particularly minimal, but rather, both to avoid @system's forced merge
39 serialization, which at least used to break portage's parallelization
40 features for a rather significant number of packages, and to be better
41 informed and active in terms of what specific packages I do have on the
42 system.)
43
44 I'll be looking forward to seeing this in a release. =:^)
45
46 --
47 Duncan - List replies preferred. No HTML msgs.
48 "Every nonfree program has a lord, a master --
49 and if you use the program, he is your master." Richard Stallman