1 |
On Sat, Apr 14, 2001 at 04:54:36PM +0200, Achim Gottinger wrote: |
2 |
|
3 |
> Daniel, I have a question, why is it easier to add a new file (package.mask) |
4 |
> that excludes packages instead of using the already existing packages file |
5 |
> for masquerading (oposite of package.mask)? |
6 |
|
7 |
Good question... and here's a (hopefully) good answer. Consider what will |
8 |
happen when we have 20 different system-profiles on portage, and you add one |
9 |
experimental package to CVS. You could either add 20 lines to |
10 |
/usr/portage/profiles/[x]/packages, or add a single exclusion line to |
11 |
/usr/portage/profiles/package.mask. Remember that package.mask is shared by |
12 |
*every* profile, while the packages file is profile-specific. package.mask is |
13 |
specifically designed so that developers can exclude experimental ebuilds by |
14 |
adding one line to one file -- ebuilds that are not stable shouldn't be used |
15 |
under *any* profile. Now, CVS committers only need to modify a single file to |
16 |
"mask out" the broken ebuilds rather than carefully tweak every existing |
17 |
profile. This will allow for us to have certain people who are just "profile |
18 |
maintainers" -- maintaining a specific directory in /usr/portage/profiles -- |
19 |
but don't actually need to be up-to-date on which ebuilds are broken and which |
20 |
work this week or the next. That's the job of the ebuild maintainers, who keep |
21 |
/usr/portage/profiles/package.mask up-to-date to protect the profile |
22 |
maintainers and end-users. |
23 |
|
24 |
Lots of _underlines_ and *stars* around key words in the next paragraph just to |
25 |
make it easier to read.... |
26 |
|
27 |
The purpose of the packages file is to describe the _minimal_ ebuilds that |
28 |
should be installed under a *specific* profile, while package.mask describes |
29 |
the files that should _not_ be installed under *any* profile. Note that if a |
30 |
package is _not_ listed in packages, it *can* still be merged by the user. So, |
31 |
the packages file is _not_ supposed to prevent merging of not-listed packages, |
32 |
but rather require merging of packages (technically, satisfaction of |
33 |
dependencies) that *are* listed. For example, if you have a "minimal" profile, |
34 |
the packages file may only have 15 entries, but the user will still be able to |
35 |
merge GNOME if they choose to do so. |
36 |
|
37 |
The purpose of this design philosophy is to help ensure a working system without |
38 |
putting unnecessary restraints on the user. Apologies for not explaining this |
39 |
earlier; I thought you understood the concept behind the packages file. In any |
40 |
case, I hope you like the design -- personally, I think it's a good approach. |
41 |
|
42 |
While I still need to figure out how to resolve conflicts between package lines |
43 |
and the DEPEND/RDEPEND strings, this does not change the fact that the packages |
44 |
file was always intended (by me, at least) to list minimal-compliance |
45 |
requirements (dependencies) for a specific profile, rather than an exhaustive |
46 |
list of every possible package that is allowed to be installed like |
47 |
current-packages.new did. That's the concept behind a system profile -- to |
48 |
identify a subset of the packages on CVS that constitute a complete system. |
49 |
|
50 |
Best Regards, |
51 |
|
52 |
-- |
53 |
Daniel Robbins <drobbins@g.o> |
54 |
President/CEO http://www.gentoo.org |
55 |
Gentoo Technologies, Inc. |