| 1 |
Zac Medico wrote: |
| 2 |
> Brian Harring wrote: |
| 3 |
> >This makes portage go looking in two different locations for |
| 4 |
> >overrides; I know from looking through the code, |
| 5 |
> >/etc/portage/package.* overrides the includes, but users won't. |
| 6 |
> |
| 7 |
> This behavior could be documented and possibly configurable. |
| 8 |
Adding another configurable to control it gets back to my point- |
| 9 |
should be a simple, extensible *singular* method of doing this, not N |
| 10 |
methods. |
| 11 |
|
| 12 |
|
| 13 |
> >Configuration in two seperate locations of the same thing is usually a |
| 14 |
> >bad idea (exempting global configuration, user configuration, which |
| 15 |
> >this is not). It's not intuitive, mainly. |
| 16 |
> |
| 17 |
> The idea behind my patch was something akin to /etc/env.d, where |
| 18 |
> it's easy to yank things in and out in groups. That makes it easy |
| 19 |
> for tools (unmasking and what else?) to make "transactional" |
| 20 |
> changes, in a sense. |
| 21 |
Not so much transactional as groupping/seperation of each apps files. |
| 22 |
(sort of). |
| 23 |
|
| 24 |
The type of changes you're talking about could just as easily be |
| 25 |
integrated into package.* with source command added to it. |
| 26 |
|
| 27 |
Where's the gain in adding a secondary location for these files, when |
| 28 |
the same can be managed from the existing with a minor tweak? |
| 29 |
|
| 30 |
> >>Index: pym/portage_util.py |
| 31 |
> >>=================================================================== |
| 32 |
> >>--- pym/portage_util.py (revision 2314) |
| 33 |
> >>+++ pym/portage_util.py (working copy) |
| 34 |
> >>@@ -463,3 +463,12 @@ |
| 35 |
> >> writemsg(line, noiselevel=1) |
| 36 |
> >> writemsg("Please file a bug for %s\n" % sys.argv[0], noiselevel=1) |
| 37 |
> >> writemsg("====================================\n\n", noiselevel=1) |
| 38 |
> >>+ |
| 39 |
> >>+def subdir_paths(parent): |
| 40 |
> >>+ full_paths=[] |
| 41 |
> >>+ if os.path.exists(parent) and os.path.isdir(parent): |
| 42 |
|
| 43 |
Two stats when os.path.isdir(parent) would suffice (single stat) |
| 44 |
|
| 45 |
> >>+ for x in os.listdir(parent): |
| 46 |
> >>+ full_path=os.path.join(parent,x) |
| 47 |
> >>+ if os.path.isdir(full_path): |
| 48 |
> >>+ full_paths.append(full_path) |
| 49 |
> >>+ return full_paths |
| 50 |
<snip> |
| 51 |
> Good points. I have to admit that I did not put much thought into that |
| 52 |
> function. Like Jason said, the paths should be sorted. It certainly needs |
| 53 |
> improvement. :) |
| 54 |
|
| 55 |
Actually, in reading this through a bit closer, it won't go recursive- |
| 56 |
the code above will only go a single dir down, which isn't |
| 57 |
really friendly- either support recursing through subdirs or don't, |
| 58 |
basically. :) |
| 59 |
|
| 60 |
~harring |
Archives