1 |
On Sun, 2004-07-25 at 11:03, Ciaran McCreesh wrote: |
2 |
> On Sun, 25 Jul 2004 11:01:15 -0500 Paul Varner |
3 |
> <gentoo-dev@××××××××××××.org> wrote: |
4 |
> | As a side note, knowing how to do this also benefits "Enterprise |
5 |
> | Gentoo". If defined correctly, it becomes a lot easier to |
6 |
> | build/rebuild systems containing the same packages on multiple |
7 |
> | machines. Since I can now define a desktop profile, a server profile, |
8 |
> | etc. If it's configurable enough I could even go so far as to |
9 |
> | defining the server profile differently based upon if it is a mail |
10 |
> | server vs. a web server, etc. |
11 |
> |
12 |
> Uhm, isn't that why we have /etc/portage/sets/ and GLEP 21? |
13 |
|
14 |
It's not completely what I'm looking for, although using sets would be |
15 |
workable. |
16 |
|
17 |
What I'm trying to accomplish is to explicitly seperate "system" |
18 |
software from "user" software. Where system software is the stuff that |
19 |
I require to be installed on a system. Typically, I have much stricter |
20 |
controls on the system stuff versus the user stuff. |
21 |
|
22 |
I'm still thinking through this stuff, but what I envision is something |
23 |
similar to the following sets: |
24 |
|
25 |
system - The set of software required for the machine to operate. This |
26 |
may be defined differently depending on the function of the machine. |
27 |
For example, if virtual/mta is part of the system, I might define |
28 |
mail-mta/ssmtp to be the MTA for a desktop and mail-mta/postfix to be |
29 |
the MTA for a server. The system software for a desktop would probably |
30 |
include X, while X would not be part of the software for a server. An |
31 |
emerge <whatever option> system would take care of all of this |
32 |
software. A web server would include apache in this list, where a file |
33 |
server or mail server would not. Depending upon policy, I would |
34 |
probably also lock this profile down to specific versions, so that |
35 |
upgrades to this set of software are not automatic and require me to |
36 |
manually update the profile to allow the upgrades. |
37 |
|
38 |
sets (as currently defined in GLEP 21) - The applications that I would |
39 |
install on a machine for it to do its intended function. A desktop set |
40 |
would probably include Open Office, a web server might have the various |
41 |
mod_* packages, and a mail server would have spamassassin and clamav. |
42 |
Depending upon policy, I may or may not care about upgrades. It might |
43 |
be locked down tight, allow automatic upgrades as long as it isn't the |
44 |
next major version, etc. |
45 |
|
46 |
world - All of the one-off stuff not installed with the system profile |
47 |
or by the set. For example: I've decided that I hate KDE/Gnome and I |
48 |
want to see if Fluxbox meets my needs. While I'm testing/playing with |
49 |
it, it would be in the world file and I don't deeply care if it breaks |
50 |
or is automatically upgraded. I see the stuff in the world file as |
51 |
being specific to the machine/users for that machine that wouldn't |
52 |
neccessarily be applicable to another machine or user. |
53 |
|
54 |
It is this kind of configurabilty that has drawn me to Gentoo in the |
55 |
first place. I've gotten fed up with the RPM hell from other distros |
56 |
and the inability to define what/how I want a machine to have installed |
57 |
in an easily repeatable and controllable fashion. The configuration |
58 |
capabilities of portage has accomplished much of my goals as a system |
59 |
administrator and user. Where I'm at now is what I consider to be the |
60 |
grey areas of configuration (i.e. my definition of system probably |
61 |
doesn't match your definition) thus my request for discussion and |
62 |
education. |
63 |
|
64 |
Regards, |
65 |
Paul |
66 |
-- |
67 |
My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo |
68 |
|
69 |
-- |
70 |
gentoo-dev@g.o mailing list |