Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 339446 - sys-apps/portage- the ebuild man page provides misleading info about what commands will be run
Summary: sys-apps/portage- the ebuild man page provides misleading info about ...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Documentation (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
Keywords: InVCS
Depends on:
Blocks: 472632
  Show dependency tree
Reported: 2010-10-02 11:14 UTC by rhywek
Modified: 2013-08-03 10:20 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

[PATCH] Fixes the bug (0001-Fix-imprecise-paragraph-bug-339446.patch,1.59 KB, patch)
2013-07-31 21:54 UTC, Alexander Berntsen (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rhywek 2010-10-02 11:14:07 UTC

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) gentoo-dev 2013-07-31 21:54:01 UTC
Created attachment 354774 [details, diff]
[PATCH] Fixes the bug
Comment 2 Zac Medico gentoo-dev 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:;a=commit;h=ffb0d6da81d1731ba165a16f702bf2465840497e
Comment 3 Zac Medico gentoo-dev 2013-08-03 10:20:15 UTC
This is fixed in and 2.2.0_alpha192.