1 |
Andreas K. Huettel <dilfridge <at> gentoo.org> writes: |
2 |
|
3 |
|
4 |
|
5 |
> You're venturing into wonderland. Expect some mad hatters to pop up. |
6 |
|
7 |
Yes! |
8 |
|
9 |
> > So my questions related to how does gentoo actually determines the exact |
10 |
> > list of programs that are minimally installed, with the specific |
11 |
> > arch and the profile selected? In previous times, I just put USE='-*' in |
12 |
> > the make.conf file and built upwards from there. |
13 |
> Don't, it breaks things. |
14 |
|
15 |
It use to work. So maybe building up from an embedded profile for a given |
16 |
arch? Problem is I'm not certain there is an "embedded" profile |
17 |
for any of the arches? If there is, then I could use that list of |
18 |
packages and tweak the list for another arch. |
19 |
|
20 |
|
21 |
|
22 |
> > Still there were baseline |
23 |
> > packages in the most minimal of stage based gentoo builds. I'm looking for |
24 |
> > a current approach to bridging between a baseline default profile (for |
25 |
> > amd64 that would be: [1] default/linux/amd64/13.0 *) and an embedded |
26 |
> > amd64 profile (if one currently exist? How do I find the potential |
27 |
> > profiles for say another arch (ppc for example), from an amd64 based |
28 |
> > gentoo system? Tools? Recommended scripts to review? |
29 |
> |
30 |
> Your best bet is the (undocumented) portage python API. I guess the |
31 |
> question is specific enough that you can pop into #gentoo-portage and |
32 |
> ask. |
33 |
|
34 |
OK. Good info. adhoc, as I suspected, burried in codes, scrips |
35 |
and data structures..... Busybox was the only common package |
36 |
I could find for embedded trees. |
37 |
|
38 |
|
39 |
|
40 |
> The choices from eselect come from /usr/portage/profiles/profiles.desc |
41 |
|
42 |
Ah! |
43 |
|
44 |
|
45 |
> About what each of these profiles does - you can find that out by |
46 |
> starting with the directory given in profiles.desc (e.g., |
47 |
> /usr/portage/profiles/hardened/linux/amd64 for choice [14]) and follow |
48 |
> the content of the "parent" files in the directories for inheritance. |
49 |
|
50 |
Ahhh! Boy some organizing tool would be keen to discern the differences. |
51 |
The next part would be the buzilla status of the profiles in comparison |
52 |
to what is common. Remember, I'm looking bottom (minimalistic upwards) |
53 |
to it should be much less that the (77) baseline packages.... |
54 |
|
55 |
There is a gap between embedded and baseline(=default); and no rhyme or |
56 |
reason. Adhoc per arch, mostly, if at all. |
57 |
|
58 |
|
59 |
> > The next thought is how then to best (succinctly) determine the complete |
60 |
> > list of packages that will be pulled into any given (arch) profile. |
61 |
> |
62 |
> Basically you have to follow the inheritance tree as defined by the |
63 |
> parent files, and add stuff up. For the detailed algorithms, see |
64 |
> app-doc/pms (good bedtime reading). |
65 |
> |
66 |
> The targets (systemd, desktop, kde, gnome) are more or less maintained |
67 |
> by the respective teams. |
68 |
> The arch dirs are maintained by the arch teams. |
69 |
> |
70 |
> Since changes to any of these dirs may affect a lot, they are usually |
71 |
> done with care and rather minimally. |
72 |
|
73 |
Yep! I keep old boxes around for such (destructive risk) noodling. |
74 |
|
75 |
|
76 |
> > Finally. What if I want to "roll my own profiles"; should I just |
77 |
> > build on one of the minimal ones or create something anew that exists |
78 |
> > only on my systems? |
79 |
|
80 |
> You *can* roll your own profiles, but it's non-trivial and can cause |
81 |
> pain. You'll probably end up asking a lot of questions before it works. |
82 |
> It took me a while to figure it out even when already knowing how the |
83 |
> main profile tree more or less works. |
84 |
|
85 |
Surely I know this. But looking for some standardization for |
86 |
"embedded-Gentoo" (i.e. the most mini-sizable possible embedded gentoo |
87 |
linux) should |
88 |
not be that difficult for most common arches we support. Getting from there |
89 |
to "minimized" and then "default" from the same arch tree (pathways) should |
90 |
be mostly the same except for things mandated by the functional differences |
91 |
of the arches themselves. I think I'm going to limit this (for now) to these |
92 |
arches (AMD64 x86_32 arm64 arm(32). |
93 |
|
94 |
|
95 |
> For an example, check my dev overlay (it adds one profile for x86 and for |
96 |
> amd64). |
97 |
|
98 |
Will do. |
99 |
|
100 |
|
101 |
> Your safest bet would be to inherit the arch main profile (e.g. |
102 |
> default/linux/amd64/13.0) and maybe remove some stuff. However, there's |
103 |
> not too much to remove left there. So I'm not sure if it's really worth |
104 |
> the effort. |
105 |
> Cheers, Andreas |
106 |
|
107 |
That is the 'top down' approach ((default --> embedded). You'd think this |
108 |
quest is the same, but I'm going to first look at this 'bottom up' (embedded |
109 |
--> minimal --> default); but much is missing. So I'll look at what exists |
110 |
in various embedded arches. I just cannot reconcile why there is no bridge |
111 |
between embedded and (some/any)minimal and default. |
112 |
|
113 |
I do understand now why you cannot (usually) change profiles; the profile |
114 |
system is a mess and really needs a whole new overall design. That's why we |
115 |
still have '13' in the profiles even though it's 2015. The entire gentoo |
116 |
profile system is showing it's age and evolutionary problems, imho. I not |
117 |
saying I'm taking on that brood of hornets, but just a few select |
118 |
migrations from embedded to minimal. |
119 |
|
120 |
|
121 |
Note {embedded << minimal << default} I still have some vintage gentoo |
122 |
systems running which have very few flags set and include (USE="-*") in |
123 |
make.conf. And a {state-machine/executive/rtos << embedded(linux)}, |
124 |
just so we are on the same page. |
125 |
|
126 |
|
127 |
thx! |
128 |
James |