Hello, This is a patch to emerge from portage 2.0.51-r15, which is to my understanding needed for the 2005.0 release. Here is a description of the functionality contained in this patch: Existing behavior: When "emerge [-u][-p] system" is run, emerge's normal behavior is to build a tree of packages to merge to ensure that the dependencies listed in the current system profile are satisfied. This patch adds a new capability to "emerge system", which causes emerge to scan for the existence of a REBUILD file as it is building the dependency tree. This file is checked on a per-tree-dependency basis and is located at: /var/db/pkg/category/package-version[-rev]/REBUILD It performs this check using the official portage aux_get() call. If REBUILD exists and is not empty, then Portage will ignore the fact that this package is installed while it is constructing the tree of packages to merge. This will have the effect of "rebuilding" (ie recompiling/remerging) the package, even though the package is already installed and may already satisfy the system profile dependency. Rationale: This new functionality is intended to be used to allow stage2 tarballs to have certain packages pre-tagged for rebuilding by the releng team, without having to resort to forcing a rebuild by actually removing the original package's metadata directory from the stage2 tarball. Historically, rebuilding was forced by deleting entire package directories from /var/db/pkg. This has been disabled recently in order to address the stray files problem. However, the ability for certain packages to be auto-rebuilt is still needed. Thus, this new functionality was created. Guidelines for use: Certain packages on a stage2 tarball need forced rebuilding for one of two reasons: 1) The package had C++ support disabled to allow itself to be built during bootstrap (when no C++ compiler was present); 2) The package had some other functionality or component disabled (such as man pages) to allow the package to either be built during bootstrap, or take up less space on the stage1. The releng team should create REBUILD files from a catalyst script by using a technique similar to the following: echo 1 > /var/db/pkg/dev-lang/python-2*/REBUILD This will tag the current version of python for rebuilding when the end-user unpacks the stage2 tarball and runs "emerge system." In this particular case, this will cause python to be rebuilt using the user's current USE settings, and with its C++ API re-enabled due to the "bootstrap" use flag not being set. NOTE: This REBUILD functionality should only be used on packages that are not slotted in a fine-grained way. This functionality is generally not suited for libraries that are meant to co-exist on a system (since the old to-be-rebuilt package will not get auto-cleaned, and thus will get rebuilt every "emerge system" call.)
Created attachment 50690 [details, diff] emerge REBUILD patch
Created attachment 50698 [details, diff] updated patch that should speed up the --newuse calculation
I updated the patch to replace a cpv_exists() call I missed. It should speed up the --newuse calculation section a bit.
Not much for this method.. Support for mixing targets and atoms would be better. `emerge sys-devel/gcc system` for example.
While I agree that moxing targets and atoms are a good capability to have. This bug was to resolve a specific problem. When we perform our stage1->stage2 bootstrapping, several packages are compiled with the user's CFLAGS/USE, etc. thata re then all *recompiled* in our stage3 "emerge system" due to our newer requirement for using "emerge -e system" when going from stage2->stage3. The original purpose of this patch was to allow for modification of catalyst to inject a REBUILD into every package in the stage1 tarball. Packages that get rebuilt during the stage1->stage2 bootstrap would be missing this REBUILD file, since it would not be built by catalyst in such a manner. Once we got to the "emerge system" stage, we would not be using "-e" at all... instead, portage would create the dependency tree for all packages that are not merged already, plus the packages with a REBUILD file in them. This way, once the stage3 is completed, each package will have been only compiled once by the user.
I also don't really like this hack, IMHO it should be handled by a wrapper script.
Well, we've been using the "rebuild everything" approach for some time now, and users haven't really been complaining, so I'm going to remove myself from CC on this. I really don't think it is necessary anymore.
Closing.
