1 |
drobbins@g.o wrote: |
2 |
|
3 |
> On Sun, Feb 18, 2001 at 05:43:22PM -0500, Jerry A! wrote: |
4 |
> > I'm thinking that this may be a good time to audit the portage tree and |
5 |
> > clean up any cruft. |
6 |
> > |
7 |
> > Specifically: |
8 |
> > |
9 |
> > 1. Clean out directories with multiple, older versions of ebuilds. |
10 |
|
11 |
That's a bit to early I have reworked 1/4 of all our packages and still have alot |
12 |
to do. |
13 |
I commit my new packages but I don't add them to current-packages.new. |
14 |
I introduced alot of new USE triggers but I'm not finished. |
15 |
|
16 |
> |
17 |
> > 2. Consolidate portages which are replicated in multiple directories. |
18 |
|
19 |
Yes there are a few packages that have been moved and the old dirs still exists. |
20 |
I think it is save to remove them physicaly from the tree. They make life more |
21 |
complicate |
22 |
as long as they are there. |
23 |
|
24 |
> |
25 |
> > 3. Consolidate current-packages and current-packages.new into one file. |
26 |
|
27 |
We can simply copy current-package.new to current-packages. |
28 |
Are there people out there who still use rc3? |
29 |
|
30 |
> |
31 |
> > |
32 |
> > Why now? Well, since it looks like most of Gentoo is falling into place |
33 |
> > and is growning everyday, now seems like a good time (in my opinion). |
34 |
> > Also, it appears as though with the new portage expansions (xpak) being |
35 |
> > the building blocks for 1.0_rc5, that this going into this with a |
36 |
> > spotless tree may make the work a lot easier. |
37 |
> > |
38 |
> > Anyway, I'd like to know what you all think. If it does appear like a |
39 |
> > good idea, then maybe we should get all the committers together, divide |
40 |
> > up the tree and go to town... |
41 |
> |
42 |
> I think that's a good idea. We may want to start discussing how to add a new |
43 |
> feature to portage called "system profiles". This new feature will allow us to |
44 |
> define a certain "type" of Gentoo Linux system, and then list all the packages |
45 |
> that are part of this system. Users will be able to select from these various |
46 |
> types at system install time. For example, a user can decide to install a |
47 |
> "minimal server" set of packages, or a "the drobbins ultimate desktop system" |
48 |
> set. I plan to record user profile information in /usr/portage/profiles, and |
49 |
> it will allow us to replace the current-packages file with a |
50 |
> /usr/portage/profiles/default file. |
51 |
> |
52 |
> Now, some questions. |
53 |
> |
54 |
> I still haven't decided how this system will work with the USE variable. Right |
55 |
> now, optional functionality can be enabled or disabled with USE in make.conf, |
56 |
> so that ebuilds know whether to compile-in optional GNOME support into |
57 |
> particular packages, for example. Will system profiles include their own |
58 |
> custom USE settings? It would seem like they'd have to. They may also have |
59 |
> other special customization files -- any you can think of? |
60 |
|
61 |
Well as long as our dependencies system can not check the USE status of an |
62 |
installed or required package |
63 |
people should not change the USE settings. |
64 |
We should put USE in the profile and maybe output a warning if packages USE |
65 |
differs from the one in make.conf |
66 |
|
67 |
> |
68 |
> |
69 |
> The USE variable also creates some complications for our .tbz2 binaries that |
70 |
> appear on the CD. What should the default USE settings be? I'm thinking that |
71 |
> our binaries could cater to a fully-configured system. If users want to set |
72 |
> up a minimal system, then can install the sys.tbz2 file, set USE appropriately, |
73 |
> and then compile everything else from sources. |
74 |
|
75 |
No he should use the build.tbz2. ( I made a shared version which requires about |
76 |
100MB instead of 130 for the statically linked one). |
77 |
|
78 |
Lot of the USE triggers I added are not really interesting for a X system like |
79 |
svga, ggi or framebuffer support. |
80 |
Others should be added like using readline, berkleydb, gdbm. |
81 |
|
82 |
These flags are interesting for embedded systems or for GPL/LGPL only systems. |
83 |
|
84 |
I will make a list of the ones I use at the moment and post it to that list. |
85 |
|
86 |
achim~ |
87 |
|
88 |
> |
89 |
> |
90 |
> Ideas, questions, comments? |
91 |
> |
92 |
> -- |
93 |
> Daniel Robbins <drobbins@g.o> |
94 |
> President/CEO http://www.gentoo.org |
95 |
> Gentoo Technologies, Inc. |
96 |
> |
97 |
> _______________________________________________ |
98 |
> gentoo-dev mailing list |
99 |
> gentoo-dev@g.o |
100 |
> http://www.gentoo.org/mailman/listinfo/gentoo-dev |