[gentoo-user] Looking at Sources

[gentoo-user] Looking at Sources

[James]

Hello,

A better method to review code?

I find myself having to audit the code inside
of ebuilds in order to understand how a given
piece of code has been changed. 

So what I do is go to the /usr/portage/distfiles 
and then use vi to look at the file listing;
move up and down to select the file of interest
and then enter the file (yes from inside of vi).
Not very elegant, but does not require unpacking the
files.

Definitely not the best approach, but, I do not
want the unpack the sources, most of the time.
Suggestions as to a better quick approach for reviewing sources?

If I want  to unpack the sources and modify
some code, what would be the recommended semantics?
Maybe make a dir under /usr/local and open the packages
as James-overlay(package), modify the code, install it
and test? (What do the "Titans of code" do?)

Maybe use/hack my own slot  numbers?
Any guidance or dev documents as to how most
G_devs do this is of keen interest to me.
I'm looking for a  (proper) methodology to start cleaning
up some codes that are neglected. Surely there
is a preferred methodology?



James

Re: [gentoo-user] Looking at Sources

[Paul Hartman]

On Wed, Nov 9, 2011 at 11:36 AM, James <wireless@tampabay.rr.com> wrote:
> Hello,
>
> A better method to review code?
>
> I find myself having to audit the code inside
> of ebuilds in order to understand how a given
> piece of code has been changed.
>
> So what I do is go to the /usr/portage/distfiles
> and then use vi to look at the file listing;
> move up and down to select the file of interest
> and then enter the file (yes from inside of vi).
> Not very elegant, but does not require unpacking the
> files.

I do the same with Midnight Commander.

> If I want  to unpack the sources and modify
> some code, what would be the recommended semantics?
> Maybe make a dir under /usr/local and open the packages
> as James-overlay(package), modify the code, install it
> and test? (What do the "Titans of code" do?)

It has to be unpacked at some point... For one-off changes to source
you can do something like:

ebuild /path/to/the.ebuild unpack
go to your portage tmpdir and edit stuff
ebuild /path/to/the.ebuild install

Keep in mind that your changes will disappear out of the tmpdir when
it's done. If you want it to persist, make a patch and use the
/etc/portage/patches mechanism to auto-apply it to future emerges of
that package.

If you're modifying ebuilds themselves then I would put it in your
local overlay.

Re: [gentoo-user] Looking at Sources

[James Broadhead]

On 9 November 2011 17:36, James <wireless@tampabay.rr.com> wrote:
> Hello,
>
> A better method to review code?
>

You seem to be talking about doing a few different things, none of
which is _quite_ what I'd call a code review.

What you're currently doing makes sense if you're interested in
finding out what some code does before you emerge it.

If you want to work on writing patches for it, then it doesn't make as
much sense.
First, a packaged file in distfiles is probably not the latest version
of the code - you should fetch the latest from version-control (no
point repeating someone else's work)
Next, creating a local overlay (/usr/local/portage) to test patches
for a program isn't a fantastic idea since your changes (and bugs!)
get installed to your system. A local overlay is usually used to test
_ebuild_ development, not program development. Dev Testing is usually
done in a development folder, and is not installed system-wide until
ready. Of course, it's nice to update ebuilds and add lines to apply
your patches before filing a gentoo / ${APP} bug report, but that's
more a near-final step in patch-writing. Take a look at the
gentoo-wiki article on creating a local overlay for info on this.

So basically, I'm advising you to check out from upstream's version
control, work on your patching inside the checkout, perform builds,
but don't "make install". Run the test builds from your development
folder (that way you can have $APP-nopatch installed and working
system-wide, and can compare to it while you're testing). Once your
patch is ready, create a local overlay + update the ebuild to apply
your patch. Finally, file those bug reports!

Happy hacking -

James

[gentoo-user] Re: Looking at Sources

[James]

James Broadhead <jamesbroadhead <at> gmail.com> writes:


> You seem to be talking about doing a few different things, none of
> which is _quite_ what I'd call a code review.

Well my experience is if you cannot hack the code a little bit,
reviews of just reading and using parsing tools, are mostly 
benign in performing a solid code review.... ymmv.


> If you want to work on writing patches for it, then it doesn't make as
> much sense.

Some times code changes rarely. Like minicom. There is no GIT
or repository activity that amounts to anything. In general,
with active projects, you are right. Much of what I'm doing
is cleaning up old, neglected code, that most do not use anymore....


> So basically, I'm advising you to check out from upstream's version
> control, work on your patching inside the checkout, perform builds,
> but don't "make install". Run the test builds from your development
> folder (that way you can have $APP-nopatch installed and working
> system-wide, and can compare to it while you're testing). Once your
> patch is ready, create a local overlay + update the ebuild to apply
> your patch. Finally, file those bug reports!

I have to delete much of your message to use gmane....


Anyway, I agree with and like your suggestions. I'm also reading 
some docs I found on overlays and gentoo development.
I guess I'll survey all of the ideas and then mostly use
what I'm use to, in a gentoo_ish approach.

Thanks to you and Paul for posting.
Yes, I'll post the patches somewhere. Some may not be
appropriate for gentoo mainline.


James