1 |
On 07/02/2014 13:54, Micha³ Górny wrote: |
2 |
> Dnia 2014-07-02, o godz. 10:44:16 |
3 |
[snip] |
4 |
> |
5 |
> I don't feel like we ought to vote on something like this without |
6 |
> understanding most of the current profiles. And I'm afraid there are |
7 |
> only few people who have any idea about the current profile |
8 |
> structure... |
9 |
> |
10 |
|
11 |
I am going to throw this out there and see what people think. Maybe it's |
12 |
insane, maybe it's not, maybe it's a mix of insane and not-insane. |
13 |
|
14 |
Years ago, before we had the current stacking profile design (we were |
15 |
discussing the current design, actually), I kinda conjured up this "building |
16 |
blocks" like approach for a profile design. Basically building on how most |
17 |
of a Gentoo system is pieced together in /etc/make.conf (or wherever that |
18 |
file lives now). A new variable, $PROFILE, would be defined that contains a |
19 |
colon-separated list of profile "blocks" that specifies the nature of the |
20 |
system. Kinda like how $PATH is built. This idea never got any traction, |
21 |
though, and may still not. |
22 |
|
23 |
Quoting from an e-mail I sent months ago to blueness after reading one of |
24 |
his blog posts, here's what I worked out years ago with some updated |
25 |
thinking a few months ago: |
26 |
|
27 |
---------------------- |
28 |
|
29 |
An idea I had at the time, but which never gained any traction, was to use a |
30 |
similar profile layout as we have now, but not treat it like a sequence of |
31 |
directory structures. Instead, the idea was to have it modeled more like |
32 |
how $PATH is built up from discrete components. |
33 |
|
34 |
So instead of something like this: |
35 |
|
36 |
/usr/portage/profiles/base |
37 |
/usr/portage/profiles/default/linux |
38 |
/usr/portage/profiles/arch/base |
39 |
/usr/portage/profiles/features/multilib |
40 |
/usr/portage/profiles/features/multilib/lib32 |
41 |
/usr/portage/profiles/arch/amd64 |
42 |
/usr/portage/profiles/releases |
43 |
/usr/portage/profiles/eapi-5-files |
44 |
/usr/portage/profiles/releases/13.0 |
45 |
/usr/portage/profiles/hardened/linux |
46 |
/usr/portage/profiles/hardened/linux/amd64 |
47 |
/usr/portage/profiles/targets/desktop |
48 |
/usr/portage/profiles/hardened/linux/amd64/destkop |
49 |
|
50 |
You would have a layout in /usr/portage/profiles look like this instead |
51 |
(btw, this is from long-term memory, so some things might be off from my |
52 |
original idea way back when): |
53 |
|
54 |
arch/ base/ desktops/ |
55 |
|-amd64/ |-e17/ |
56 |
|-arm/ |-kde/ |
57 |
|-mips/ |-gnome/ |
58 |
|-sparc/ |-xfce/ |
59 |
|-x86/ |
60 |
|
61 |
eapi/ kernel/ libc/ |
62 |
|-3/ |-freebsd/ |-glibc |
63 |
|-4/ |-linux/ |-uclibc |
64 |
|-5/ |-musl |
65 |
|-6/ |-freebsd |
66 |
|
67 |
options/ releases/ roles/ |
68 |
|-hardened/ |-11.0/ |-desktop/ |
69 |
|-multilib/ |-12.0/ |-firewall/ |
70 |
|-13.0/ |-ids/ |
71 |
|-freebsd-9.2/ |-router/ |
72 |
|-server/ |
73 |
|
74 |
servers/ subarch/ |
75 |
|-dns/ |-mips-o32 |
76 |
|-file/ |-mips-n32 |
77 |
|-mail/ |-sparc-v8 |
78 |
|-www/ |-amd64-x32 |
79 |
|
80 |
The idea being that, in /etc/make.conf (or wherever that file is now), you'd |
81 |
define $PROFILE like this: |
82 |
|
83 |
linux-mips o32 uclibc server: |
84 |
PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0" |
85 |
|
86 |
linux-amd64/x86_64/x64 glibc hardened 13.0 KDE desktop: |
87 |
PROFILE="base:kernel/linux:arch/amd64:libc/glibc:roles/desktop:options/hardened:desktops/kde:releases/13.0" |
88 |
|
89 |
freebsd-amd64 9.2 firewall: |
90 |
PROFILE="base:kernel/freebsd:arch/amd64:libc/freebsd:roles/firewall:releases/freebsd-9.2" |
91 |
|
92 |
And so on. The goal was to have profiles/ be extremely flat, with limited |
93 |
nesting only for categorization purposes. Each component would contain all |
94 |
of the information specific to that component, and rely on OOP-like |
95 |
inheritance to override parent-level variables only within that component |
96 |
(although, <arch> and <kernel> would have to be a little bit more broad in |
97 |
scope). |
98 |
|
99 |
PROFILE also had a set order for the first few pieces, if only to make |
100 |
parsing and building the profile stack saner for the Portage developers: |
101 |
PROFILE="base:<KERNEL>:<ARCH>[:<SUBARCH>]:<LIBC>:<EVERYTHING_ELSE>" |
102 |
|
103 |
base - Core Gentoo/Portage/whatever information/vars/foobar/kittens |
104 |
|
105 |
kernel - Specifies the OS kernel. At the time, only Linux existed, but |
106 |
I *think* Debian was eyeballing kFreeBSD at the time. So I *think* |
107 |
I accounted for it back then. |
108 |
|
109 |
arch - Machine arch-specific generic information -- doesn't handle |
110 |
lower-level things like ISAs/ABIs/Endian, etc. |
111 |
|
112 |
subarch - Defines items specific given to given subarch of a main arch. |
113 |
Items under this directory would carry their parent arch's |
114 |
name for clarity only. Again, at the time, MIPS would have been |
115 |
the only real user of this, and, back then, it would've dealt |
116 |
with SGI-machine-specific packages and USE flags, such as |
117 |
differentiating an ip32 machine from an ip27 machine or a |
118 |
cobalt. Now that amd64/x86_64 is considering its own form of |
119 |
n32 (x32), that would go here, and I imagine arm would |
120 |
make heavy use of it as well. |
121 |
|
122 |
libc - Defines the main C library used. A bit redundant for *BSD, because |
123 |
they really only have one, but might help if we ever add k*BSD |
124 |
support (such as freebsd/glibc-based or such). For Linux...could be |
125 |
tricky, since there are so many libc possibilities there. I feel it |
126 |
fits better getting defined after <SUBARCH>, especially in the case |
127 |
of MIPS. |
128 |
|
129 |
desktops - Settings for specific desktops if "roles/desktop" is specified |
130 |
in $PROFILE. |
131 |
|
132 |
eapi - EAPI didn't exist back when this topic was visited. Basically, |
133 |
everything was EAPI=0 and there was only Portage (Paludis nor |
134 |
pkgcore had been invented yet). |
135 |
|
136 |
options - Was a different name back then. Basically, hardened was the only |
137 |
alternate mode available back then. Multilib hadn't even been |
138 |
thought of, because MIPS was the only arch that even had to worry |
139 |
about it, and most people were both scared and confused by the |
140 |
thought of multiple ABIs. |
141 |
|
142 |
releases - I don't think this existed back then. How it'd operate |
143 |
nowadays, I have no idea. Probably would contain |
144 |
version-specific maskings for specific @system packages |
145 |
to facilitate upgrading, and help us if we ever tried to cut |
146 |
actual, fixed release points again (like what FreeBSD does |
147 |
w/ -RELEASE-x.y) |
148 |
|
149 |
roles - Just thought this one up, as back then, we only had desktop and |
150 |
server. It'd basically define a minimal set of recommended |
151 |
packages necessary to qualify that role. I.e., desktop/kde |
152 |
would install KDE, Qt, and other related packages, while ids/ |
153 |
would install say, snort and tcpdump for packet inspection. |
154 |
|
155 |
servers - Like "desktops" above, defines minimal settings for specific |
156 |
server types. So "servers/www" would drag in apache, and |
157 |
"servers/dns" would attempt to pull in BIND. Obviously, |
158 |
there would need to be a way to override the core software |
159 |
element for a given server role -- Maybe USE flags could be |
160 |
modified to handle this (so that -apache +lighthttpd swaps |
161 |
apache out for lighthttpd). Needs a lot more thinking on |
162 |
this one. |
163 |
|
164 |
---------------------- |
165 |
|
166 |
Thoughts? |
167 |
|
168 |
-- |
169 |
Joshua Kinard |
170 |
Gentoo/MIPS |
171 |
kumba@g.o |
172 |
4096R/D25D95E3 2011-03-28 |
173 |
|
174 |
"The past tempts us, the present confuses us, the future frightens us. And |
175 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
176 |
|
177 |
--Emperor Turhan, Centauri Republic |