Bug 339446 – sys-apps/portage-2.1.8.3: the ebuild man page provides misleading info about what commands will be run

• Product: Portage Development
• Status: RESOLVED FIXED

[Description rhywek 2010-10-02 11:14:07 UTC]

Hi.

I wanted to make a patch for some app, and use portage for it. So I've made my own overlay copy of the package ebuild and I utilized the 'ebuild' command to prepare the source, like so:

# ebuild wesnoth-1.8.4.ebuild prepare

Now I have modified some source files in the prepared working directory. What I wanted to do next is to continue the merging process after the prepare stage. In other words, I wanted to run the next actions after prepare, i.e. configure, compile, etc., but I did not want to run the actions up to and including prepare, i.e. I didn't want fetch, unpack and prepare, because I didn't want my modifications to the source code to be lost.

Since I've never used ebuild before for this, I turned to the man page to find how to run some actions after the specified one (I wanted all after 'prepare'). But in my opinion the man page is very misleading about this, because after reading the man page I thought there is no way of doing it. The man page only mentions FEATURES="noauto" as a solution to my problem, and running the actions one by one myself. But after googling for an hour or so I found that actually I can get what I want, it's just not documented. So I can simply execute:

# ebuild wesnoth-1.8.4.ebuild configure
>>> Existing ${T}/environment for 'wesnoth-1.8.4' will be sourced. Run
>>> 'clean' to start with a fresh environment.
 * wesnoth-1.8.4.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...                                                                        [ ok ]
 * checking ebuild checksums ;-) ...                                                                                            [ ok ]
 * checking auxfile checksums ;-) ...                                                                                           [ ok ]
 * checking miscfile checksums ;-) ...                                                                                          [ ok ]
 * checking wesnoth-1.8.4.tar.bz2 ;-) ...                                                                                       [ ok ]
 * CPV:  games-strategy/wesnoth-1.8.4
 * REPO: 
 * USE:  amd64 dbus elibc_glibc kernel_linux nls userland_GNU
>>> Checking wesnoth-1.8.4.tar.bz2's mtime...
>>> WORKDIR is up-to-date, keeping...
>>> It appears that 'wesnoth-1.8.4' is already prepared; skipping.
>>> Remove '/var/tmp/portage/games-strategy/wesnoth-1.8.4/.prepared' to force prepare.
>>> Configuring source in /var/tmp/portage/games-strategy/wesnoth-1.8.4/work/wesnoth-1.8.4 ...

As you can see (and I guess you know it very well), the stages up to and including prepare have been skipped, because I executed 'ebuild ... prepare' already once before. So the behavior that I wanted (one of skipping some stages) is actually there, except that the man page does not mention it. The man page says that:

"By default, portage will execute all the functions in order up to the one actually specified.  For example, simply
       issuing  the  command  compile will trigger the functions before it to also be run (such as setup and unpack)."

In my opinion this description is incorrect. By default the executed actions are in order up to the one actually specified, except for the ones that have been already done in previous invocations of the ebuild command.

So that's what this bug is about, i.e. fixing the man page so this very useful behavior is described.

Reproducible: Always

Steps to Reproduce:

[Comment 1 Alexander Berntsen (RETIRED) 2013-07-31 21:54:01 UTC]

Created attachment 354774 [details, diff]
[PATCH] Fixes the bug

[Comment 2 Zac Medico 2013-07-31 21:59:42 UTC]

(In reply to Alexander Berntsen from comment #1)
> Created attachment 354774 [details, diff] [details, diff]
> [PATCH] Fixes the bug

Thanks, this is in git:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ffb0d6da81d1731ba165a16f702bf2465840497e

[Comment 3 Zac Medico 2013-08-03 10:20:15 UTC]

This is fixed in 2.1.13.3 and 2.2.0_alpha192.