"Vladimir G. Ivanovic" <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Thu,
19 Oct 2006 14:38:25 -0700:
> That being said, I'd like to see the patch even if it's in an inoperative
> state, just to see what's involved.
OK, here you go. It was a bit of a hack but it worked for my purposes.
You can see the dates and portage version number, which gives you an idea
of how stale these are. My initials are JED, so I use that to distinguish
stuff I've changed and avoid namespace collisions.
What the first part does is add a check for an environmental variable
JEDPortageSkipCompile. If found, the actual src_compile call (the stuff
in the ebuild) is skipped, but portage does the rest of its compile step,
mainly shuffling metadata around so it there where expected to be used in
the install/package/qmerge steps later, as if the src_compile call had
completed normally, but critically also creating that .compiled file.
The second part, which /may/ not be needed any more if I've read portage
changelogs and dev remarks correctly, simply added the missing check for
.compiled, directly paralleling the similar existing checks for .unpacked
and (IIRC) .installed. Given the file was created, I think missing the
check was an oversight, but it wasn't there in these old portage versions
anyway, so I had to add it.
The third part is simply a patch to be applied to the portage ebuild,
invoking the patch to portage itself. Again, the dates and portage
version numbers tell the age. I'd obviously changed this one later than
the other one.
Usage after applying the patches was as follows.
If the compile step crashed, I could investigate and fix the problem if
necessary, then run whatever compile steps needed to be completed
manually, in the working dir. Usually this simply meant rerunning the
make command, but sometimes there'd be a bit more to it. One looks at the
src_compile step in the ebuild to figure that out, but the important thing
was not having to rerun .configure thereby often eliminating much of the
compiling that had already been done, unless I had to.
After manually completing the make and/or anything else the ebuild's
src_compile did, I'd then "export JEDPortageSkipCompile=true", and run
ebuild <package> merge or package or whatever. (I always used package as I
created binpackages, then ran emerge -K to merge the binpkg, but those
uninterested in FEATURES=buildpkg could simply use ebuild <package> merge
and be done with it.)
After completing the package, don't forget to unset JEDPortageSkipCompile
if you will be doing anything else with portage, or you'll end up with a
bunch of empty packages! =8^(
--- portage-2.0.51-r3/bin/ebuild.sh 2004-10-18 21:58:42.000000000 -0700
+++ portage/bin/ebuild.sh 2004-11-07 00:48:24.025367508 -0700
@@ -912,7 +912,8 @@
#some packages use an alternative to $S to build in, cause
#our libtool to create problematic .la files
export PWORKDIR="$WORKDIR"
- src_compile
+# JED> src_compile
+ [ -z $JEDPortageSkipCompile ] && src_compile
#|| abort_compile "fail"
cd "${BUILDDIR}"
touch .compiled
@@ -1003,6 +1003,14 @@
dyn_install() {
trap "abort_install" SIGINT SIGQUIT
+# JED>
+ if [ ${BUILDDIR}/.installed -nt "${WORKDIR}" -a -d ${BUILDDIR}/image ];
then
+ echo ">>> It appears that ${PN} is already installed; skipping."
+ echo ">>> (Delete ${BUILDDIR}/.installed to force reinstall.)"
+ trap SIGINT SIGQUIT
+ return
+ fi
+# JED<
rm -rf "${BUILDDIR}/image"
mkdir "${BUILDDIR}/image"
if [ -d "${S}" ]; then
--- /p/sys-apps/portage/portage-2.0.51.22-r1.ebuild 2005-05-29
01:35:53.000000000 -0700
+++ /usr/local/p/sys-apps/portage/portage-2.0.51.22-r1.ebuild 2005-05-31
10:06:38.000000000 -0700
@@ -26,8 +26,12 @@
src_unpack() {
unpack ${A}
cd "${S}"
patch -p1 < ${FILESDIR}/2.0.51.22-fixes.patch
+
+# JED > patches
+ patch -p1 </usr/local/src/patch/portage/jed-portage.patch
+# JED < patches
}
src_compile() {
python -O -c "import compileall; compileall.compile_dir('${S}/pym')"
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
[email protected] mailing list
