| 1 |
On 01/03/2010 12:48 AM, Amit Dor-Shifer wrote: |
| 2 |
> Yes, but AFAIK, enabling a USE flag by-default only affects the enabling |
| 3 |
> ebuild, not its dependencies. Specifically, By setting "+myflag" in an |
| 4 |
> ebuild, I cannot incur a rebuild of a dependent which is also using this |
| 5 |
> flag. |
| 6 |
|
| 7 |
Right, but if the ebuild has a USE dependency (supported with EAPI |
| 8 |
2) then at least emerge will notify the user that they need to |
| 9 |
enable the flag. |
| 10 |
|
| 11 |
> Appending "myflag" to the USE set via a profile would achieve that |
| 12 |
> behavior. |
| 13 |
> |
| 14 |
>> |
| 15 |
>>> In a/m bug, the lack of documentation in this area is mentioned . I'm |
| 16 |
>>> wondering if this has changed since those comments were written, as I'm |
| 17 |
>>> confounded by bits and pieces I'm fishing out w/google. |
| 18 |
>>> |
| 19 |
>> |
| 20 |
>> The information in the wiki seems current. |
| 21 |
>> |
| 22 |
> Would that be http://en.gentoo-wiki.com/wiki/Overlay ? |
| 23 |
> If so, then |
| 24 |
> |
| 25 |
> * your a/m comment #6 in the bug, clarifying that the 'profiles' |
| 26 |
> directory has nothing to do with portage profiles is most valuable. |
| 27 |
> |
| 28 |
> <QUOTE> |
| 29 |
> |
| 30 |
> Don't let the directory name "profiles" make you think that it has |
| 31 |
> anything to do with a profile |
| 32 |
> |
| 33 |
> <UNQUOTE> |
| 34 |
> Well, it actually did make me think that. it looked plausible that |
| 35 |
> an overlay could extend a portage profile. |
| 36 |
|
| 37 |
It's a common assumption, but doing that is not necessarily a |
| 38 |
desirable because it can be invasive. Often, a user simply wants to |
| 39 |
use some ebuilds from an overlay without having it triggering an |
| 40 |
invasive bunch of global configuration changes. |
| 41 |
|
| 42 |
> * The article also mentions "portage overlay specifications", but |
| 43 |
> does not cite it. |
| 44 |
|
| 45 |
repo_name is documented in `man 5 portage`. |
| 46 |
|
| 47 |
> * That an overlay can extend package.[un]mask is also not mentioned |
| 48 |
> there. |
| 49 |
|
| 50 |
Yes, the 'global' package.[un]mask files in the root profiles/ |
| 51 |
directory do extend those from the main portage tree, but this |
| 52 |
behavior is not necessarily desirable because it can be invasive. |
| 53 |
There was some complaint in the past about the gnome overlay relying |
| 54 |
on this behavior since alternative package managers (paludis and |
| 55 |
pkgcore) didn't support it and they did not intend to add support |
| 56 |
for it. |
| 57 |
|
| 58 |
> I'm currently reluctant to contribute documentation myself, since I'm |
| 59 |
> lacking key concepts. I'd be happy to do so if I had a more thorough |
| 60 |
> understanding. |
| 61 |
|
| 62 |
Let us know if you have any more questions. |
| 63 |
-- |
| 64 |
Thanks, |
| 65 |
Zac |
Archives