On Tue, 8 Jan 2008 15:11:09 +0200 Alan McKinnon <[EMAIL PROTECTED]> wrote:
> > A much better way would be to modify the ebuild to do what you want, > then copy it to a local overlay. Portage will use your overlay in > preference to the portage tree. You just have to then watch out for > newer versions to hit the tree which will supercede your custom > ebuild, and modify those new versions similarly. Yes, may be it's time for me to learn how to write an ebuild. My problem is that it seems to me too much work just to maintain a few occasional packages locally. ;-) > There's an environment variable EXTRA_ECONF intended for *users* to > add extra configure options when emerging, but I have heard bad > things about using this. Don't know the details, perhaps someone else > who does will post in response. Yes, I'm aware of EXTRA_ECONF and I use it via /etc/portage/bashrc. ( explained w/ example by Mr. Bo Andresen: http://tinyurl.com/39c74x ) It never caused problems here. I want to change the "./configure --params" for sure but perhaps I'd need to alter several source files. I'm not sure if /etc/portage/bashrc could do the work in the latter case but it's an idea that never occurred to me before and I'm going to explore. > > Finally, you could just mask out mplayer entirely and build it from > source using the default DESTDIR of /usr/local. It's not a complete > unistall solution, but at least it doesn't collide with portage's > installs in /usr/ > Why mask? If I install it manually there would be no need for "emerge mplayer" at all, right? ;-) (additionally "/usr/local/(s)bin" precedes "/usr/(s)bin" in $PATH by default) Anyways, this is not an option for me because I hate cleaning forgotten files or keeping the src for eventual "make uninstall". I'd prefer compiling the program with PREFIX="$HOME/program_name". So, for the time being I'll try to solve the problem via "/etc/portage/bashrc", while waiting for more possible advices. -- Best regards, Daniel -- [email protected] mailing list
