| 1 |
On Tuesday 08 January 2008, Daniel Iliev wrote: |
| 2 |
> On Tue, 8 Jan 2008 15:11:09 +0200 |
| 3 |
> |
| 4 |
> Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 5 |
> > A much better way would be to modify the ebuild to do what you |
| 6 |
> > want, then copy it to a local overlay. Portage will use your |
| 7 |
> > overlay in preference to the portage tree. You just have to then |
| 8 |
> > watch out for newer versions to hit the tree which will supercede |
| 9 |
> > your custom ebuild, and modify those new versions similarly. |
| 10 |
> |
| 11 |
> Yes, may be it's time for me to learn how to write an ebuild. My |
| 12 |
> problem is that it seems to me too much work just to maintain a |
| 13 |
> few occasional packages locally. ;-) |
| 14 |
|
| 15 |
It is a reasonable amount of work to read the man pages and so on, but I |
| 16 |
found it was well worth the trouble. Now when I read an ebuild I |
| 17 |
understand what I'm seeing, before it was just meaningless stuff. |
| 18 |
|
| 19 |
Am I correct in saying you plan to emerge mplayer with a few extra |
| 20 |
params and not much else customizing? In that case the mods you will |
| 21 |
make are simple and need to be done just once. Then paste the same |
| 22 |
changes into a new ebuild each time you want to upgrade |
| 23 |
|
| 24 |
> > There's an environment variable EXTRA_ECONF intended for *users* to |
| 25 |
> > add extra configure options when emerging, but I have heard bad |
| 26 |
> > things about using this. Don't know the details, perhaps someone |
| 27 |
> > else who does will post in response. |
| 28 |
> |
| 29 |
> Yes, I'm aware of EXTRA_ECONF and I use it via /etc/portage/bashrc. |
| 30 |
> ( explained w/ example by Mr. Bo Andresen: http://tinyurl.com/39c74x |
| 31 |
> ) It never caused problems here. |
| 32 |
|
| 33 |
Interesting. I must find out more :-) |
| 34 |
|
| 35 |
> I want to change the "./configure --params" for sure but perhaps I'd |
| 36 |
> need to alter several source files. I'm not sure if |
| 37 |
> /etc/portage/bashrc could do the work in the latter case but it's an |
| 38 |
> idea that never occurred to me before and I'm going to explore. |
| 39 |
> |
| 40 |
> > Finally, you could just mask out mplayer entirely and build it from |
| 41 |
> > source using the default DESTDIR of /usr/local. It's not a complete |
| 42 |
> > unistall solution, but at least it doesn't collide with portage's |
| 43 |
> > installs in /usr/ |
| 44 |
> |
| 45 |
> Why mask? |
| 46 |
|
| 47 |
Just a safety net really, in case you one day forget and run 'emerge |
| 48 |
mplayer'. Not necessary for operation :-) |
| 49 |
|
| 50 |
|
| 51 |
|
| 52 |
-- |
| 53 |
Alan McKinnon |
| 54 |
alan dot mckinnon at gmail dot com |
| 55 |
-- |
| 56 |
gentoo-user@l.g.o mailing list |
Archives