| 1 |
Hi Seemant, |
| 2 |
|
| 3 |
A few questions about the cascading profiles. (Without reading the |
| 4 |
howto because I couldn't find the location where it was committed.) |
| 5 |
Could you add the info to the howto if missing? |
| 6 |
|
| 7 |
|
| 8 |
1. Inheriting the parent |
| 9 |
|
| 10 |
gentoo-x86/profiles/default-linux/x86/2004.0 and some other directories |
| 11 |
have parent set to ".". In most operating systems ".." is used to |
| 12 |
indicate the parent directory. In most operating systems "." indicates |
| 13 |
the current directory. Are these profiles inheriting themselves, or is |
| 14 |
"." the new way of specifying the parent? |
| 15 |
|
| 16 |
|
| 17 |
2. Package.build |
| 18 |
|
| 19 |
Package.build is inherited too. Package.build defines an order in which |
| 20 |
packages need to be emerged for stage1. What special syntax is provided |
| 21 |
to do this? Can I add a package to the beginning, the end or to a |
| 22 |
specific location of the packages.build I am inheriting from? My |
| 23 |
current guess is that the entire packages.build is just overridden. How |
| 24 |
does that relate to easier maintenance of a profile? |
| 25 |
|
| 26 |
|
| 27 |
3. Packages |
| 28 |
|
| 29 |
What syntax is provided to remove a package that is incorrectly listed |
| 30 |
as required for the system profile in the parent profile? How are |
| 31 |
conflicts handled? |
| 32 |
|
| 33 |
|
| 34 |
4. Use.defaults and use.mask |
| 35 |
|
| 36 |
The use.mask and use.defaults for the entire default-linux/x86 |
| 37 |
directory is empty. The base profile lists 'svga' as a default use |
| 38 |
flag. On ppc it should be not default but masked. Should I: |
| 39 |
|
| 40 |
a) touch the base profile and update all the inheriting profiles |
| 41 |
committing to a large number of files at once, and fix the merge |
| 42 |
conflicts |
| 43 |
b) use some sort of syntax to undo the default use flag and add it as |
| 44 |
use.mask for ppc, rendering the ppc top profile much larger to maintain |
| 45 |
|
| 46 |
How does this relate to easier profile maintenance, scalability of |
| 47 |
number of alternative architectures? |
| 48 |
How can I find out what profiles inherit a profile? |
| 49 |
|
| 50 |
|
| 51 |
5.default-linux |
| 52 |
|
| 53 |
Couldn't you have used a cascading profile for this name too? |
| 54 |
|
| 55 |
default/linux default/bsd ... instead of default-linux/ default-bsd/ ... |
| 56 |
|
| 57 |
|
| 58 |
|
| 59 |
When considering inheritance, one should think about the following |
| 60 |
aspects: |
| 61 |
|
| 62 |
- overriding |
| 63 |
- multiple inheritance |
| 64 |
- circular inheritance (profiles inheriting each other) |
| 65 |
- conflict resolution for simple and complex situations (profile A says |
| 66 |
when installed, a package version should be larger than 1.4, and |
| 67 |
another profile says it should be smaller than 1.6, ...) |
| 68 |
|
| 69 |
Also, is there an easy way to check what are the profile settings |
| 70 |
currently in effect, after applying inheritance etc? |
| 71 |
What will be the preferred way to watch commits to shared profiles? |
| 72 |
I guess catalyst will need to change to the bootstrap-cascading.sh. |
| 73 |
Will catalyst place its output also in a deep directory |
| 74 |
default/linux/x86/2004.0? When can we start testing this change to |
| 75 |
catalyst? Have the catalyst maintainers be notified? |
| 76 |
|
| 77 |
Please also read previous email when you're less busy. Feature 2 is |
| 78 |
your feature and I already asked some of these questions there. I |
| 79 |
really invest time in these emails because they affect one of the |
| 80 |
area's I'm responsible for. I should be doing more important things. |
| 81 |
|
| 82 |
Best regards, |
| 83 |
|
| 84 |
Pieter Van den Abeele |
Archives