On Sat, Sep 6, 2014 at 12:50 AM, Saifi Khan <saifik...@datasynergy.org> wrote: >
It looks like sping already bumped 1.8.0.20 in the tree, by simply renaming the existing 1.8.0.11 ebuild. I'll explain a bit more since you're interested and are simply not doing it right... > Here are things i explored: > > 1. simply renaming did not work > (it should not since the md5 hashes would not match) The hashes are not stored in the ebuild, so simply copying the existing ebuild is fine. You just need to regenerate the hashes. Repoman manifest or ebuild oracle-jdk-bin-1.8.0.20.ebuild manifest would be the easiest ways to do that. > > 3. next i attempted creating a separate file in > /usr/portage/metadata/md5-cache/dev-java for oracle-jdk-bin-1.8.0.20 file > > with 'repoman manifest' it did not work Don't mess with the metadata cache. It is not necessary. All you need to do is update the Manifest file in the package directory. When portage finds a bad/missing hash it always checks it before bailing out, and portage can generally detect an outdated cache anyway. > > however emerge started complaining about missing jdk's for i586, solaris > etc. > > Meanwhile i took a close look at the /usr/portage/eclass directory > and also tried to locate where 'inherit' is defined. > > 'inherit' is a function defined in /usr/lib/portage/bin/ebuild.sh file with > its bucket full of 'bash'isms. Before reverse-engineering PMS, you might just start with: http://devmanual.gentoo.org/ebuild-writing/using-eclasses/index.html Or, if you're really brave: http://dev.gentoo.org/~ulm/pms/head/pms.html Tweaking ebuilds isn't hard - you just need to go about it the right way and make the tools work for you. Actually, one thing I didn't see in the docs is more user-centric ebuild 101 stuff like "how do I bump an ebuild myself?" All the info is there, but not at that level. -- Rich
