| 1 |
On Fri, Nov 18, 2005 at 09:25:57AM -0800, Zac Medico wrote: |
| 2 |
> Brian Harring wrote: |
| 3 |
> >The type of changes you're talking about could just as easily be |
| 4 |
> >integrated into package.* with source command added to it. |
| 5 |
> > |
| 6 |
> >Where's the gain in adding a secondary location for these files, when |
| 7 |
> >the same can be managed from the existing with a minor tweak? |
| 8 |
> > |
| 9 |
> |
| 10 |
> I'm open to your idea of using a source command instead. I suppose that an |
| 11 |
> unmasking tool could create new package.* files and that those could then |
| 12 |
> be sourced easily enough. |
| 13 |
> |
| 14 |
> The main difference that I see is that the directories approach allows a |
| 15 |
> set of package.* files to be grouped logically. An alternative to my first |
| 16 |
> implementation would be to include paths from a variable in make.conf, akin |
| 17 |
> to PORTDIR_OVERLAY. |
| 18 |
|
| 19 |
The downside is in doing rename games to disable files/directories- |
| 20 |
plus having configuration data in two seperate locations. |
| 21 |
|
| 22 |
I'd posit for PORTDIR_OVERLAY's, if you're trying to pull in a repo |
| 23 |
specific set of package.*, that should be done as a profile mod, |
| 24 |
rather then user config. |
| 25 |
|
| 26 |
> >Two stats when os.path.isdir(parent) would suffice (single stat) |
| 27 |
> > |
| 28 |
> |
| 29 |
> I tend to avoid seemingly insignificant performance enhancements, but for |
| 30 |
> the sake of atomicity, I would opt for a single stat. |
| 31 |
If you look in os.path.isdir, you'd see it's already doing it's own |
| 32 |
os.path.exists, and returning False when exists fails. |
| 33 |
|
| 34 |
Being a mild pita on this one, but I'm not much for innefficient code |
| 35 |
leaking into portage. |
| 36 |
|
| 37 |
We've got enough of it already. |
| 38 |
~harring |
Archives