Summary: | ebuild environment should be properly saved and reused, and general cleanup | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Brian Harring (RETIRED) <ferringb> |
Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anigel, basic, blubb, dwhurt, java, masterdriverz, seemant, solar, vapier, zlin |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 40993, 46223, 51370, 52652, 54652, 125493, 200044 | ||
Attachments: |
portage.py.patch
ebuild.sh v1 ebuild-default-functions.sh ebuild-functions.sh portage.py.patch v2 ebuild.sh v2 |
Description
Brian Harring (RETIRED)
2004-07-07 21:39:24 UTC
Created attachment 34978 [details, diff]
portage.py.patch
Patch to stop doebuild from wiping ${T}; this is clean's job.
Created attachment 34979 [details]
ebuild.sh v1
ebuild.sh . No point in submitting a diff, I've moved things around *way* too
much for the diff to be sane (although ignoring white space might make it
saner).
ebuild.sh is purely the arg processing, and env handling code. All
non-essential functions have been moved out for the sake of keeping things neat
and clean.
Debug code is disabled, but currently left in place.
Created attachment 34980 [details]
ebuild-default-functions.sh
ebuild.sh's internal functions; these are all marked readonly, and not saved in
the ebuild's env.
Think of it as ebuild.sh's internal/req'd functions.
Created attachment 34981 [details]
ebuild-functions.sh
functions saved in the packages saved env. use_with/use_enable, etc.
Functions that may change, and *will* directly affect that ebuild down the
line.
These functions are able to change w/out issue- the functions defined in
-default-functions should maintain their return behaviours.
Basically think of this as ebuild.sh's api for ebuilds (horrid description, but
it'll do).
To give a general idea of how much abuse this code has been put through, keep in mind this is a split up ebuild.sh w/ a lot of env loving applied- basically I didn't change code unless I had to. So large portions of the code have already been tested prior to me shifting them around. Additionally, I brought my system up from a stage1 to full xorg-x11/flux/mozilla/etc using these patches. The modifications have behaved rather well. /me shuts up after that flood of patches/files/comments :) Created attachment 35014 [details, diff]
portage.py.patch v2
Uploaded an old patch that left out the fix for setup cleansing.
Now $T is only cleansed during the clean ebuild phase.
Created attachment 35262 [details]
ebuild.sh v2
One line adjustment changing
source /etc/init.d/functions.sh
to
source /etc/init.d/functions.sh ${EBUILD_PHASE}
Otherwise, /etc/init.d/functions will make a portageq call, *horrendously*
slowing things down.
A suggestion, I think we should make sure that it is still possible to change an ebuild and then just go on with the stage we were. This is very helpfull for development (could be feature protected though), saving precious time unpacking things for the umpteenth time, and preserving the compile history. Similarly, ebuild might be coded such that in some cases changes in command line useflags are incorporated. I see no point in allowing use flags to change midway through the build process, since it allows for the possibility of earlier phases assuming xyz to be true, and later stages assuming zyx to be true. The changes induced in cvs to protect the env are intended to ensure the build process is exact in it's usage of the env, same for removal of packages. Basically, these changes ensure things are correct, at the expense of a bit of flexibility for the developer who is attempting to walk through each phase continually adjusting the ebuild. Personally, what I do is this- if I'm walking through the phases of an ebuild w/ this code, and want to make a change, I just modify the saved environment. That is what's used, and is easy to tweak. Test the changes w/in the saved env, then add them into the ebuild. Worth noting for those using portage-cvs or these patches (or the ebd patchset), the detection of completed phases is no longer a collection of "does blah exist"- /var/tmp/portage/${P}/.completed_stages holds the list of phases that have finished. As to why I *really* dislike this request, you're basically after making the env non-linear via an opt. building/merging of the package for the user -will- be linear in env handling, as such, the dev should be testing the ebuild under that setup. They can always modify the saved env if they're walking the phases and doing debugging... *** Bug 42941 has been marked as a duplicate of this bug. *** This is in portage cvs head (has been for about ~3 months). Fixed on or before 2.0.51.22-r1 Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened. This bug is still an issue, although most of the dependencies have been worked around in a fashion. So... leave 'er closed, it's fixed in what's being worked on for next version. Not fixed... it's not in stable. *** Bug 110098 has been marked as a duplicate of this bug. *** |