| 1 |
On Wed, Nov 9, 2011 at 11:36 AM, James <wireless@×××××××××××.com> wrote: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
> A better method to review code? |
| 5 |
> |
| 6 |
> I find myself having to audit the code inside |
| 7 |
> of ebuilds in order to understand how a given |
| 8 |
> piece of code has been changed. |
| 9 |
> |
| 10 |
> So what I do is go to the /usr/portage/distfiles |
| 11 |
> and then use vi to look at the file listing; |
| 12 |
> move up and down to select the file of interest |
| 13 |
> and then enter the file (yes from inside of vi). |
| 14 |
> Not very elegant, but does not require unpacking the |
| 15 |
> files. |
| 16 |
|
| 17 |
I do the same with Midnight Commander. |
| 18 |
|
| 19 |
> If I want to unpack the sources and modify |
| 20 |
> some code, what would be the recommended semantics? |
| 21 |
> Maybe make a dir under /usr/local and open the packages |
| 22 |
> as James-overlay(package), modify the code, install it |
| 23 |
> and test? (What do the "Titans of code" do?) |
| 24 |
|
| 25 |
It has to be unpacked at some point... For one-off changes to source |
| 26 |
you can do something like: |
| 27 |
|
| 28 |
ebuild /path/to/the.ebuild unpack |
| 29 |
go to your portage tmpdir and edit stuff |
| 30 |
ebuild /path/to/the.ebuild install |
| 31 |
|
| 32 |
Keep in mind that your changes will disappear out of the tmpdir when |
| 33 |
it's done. If you want it to persist, make a patch and use the |
| 34 |
/etc/portage/patches mechanism to auto-apply it to future emerges of |
| 35 |
that package. |
| 36 |
|
| 37 |
If you're modifying ebuilds themselves then I would put it in your |
| 38 |
local overlay. |
Archives