On Tue, 8 Jan 2008 15:11:09 +0200
Alan McKinnon <alan.mckinnon@gmail.com> 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
--
gentoo-user@lists.gentoo.org mailing list

On Tuesday 08 January 2008, Daniel Iliev wrote:
> On Tue, 8 Jan 2008 15:11:09 +0200
>
> Alan McKinnon <alan.mckinnon@gmail.com> 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. ;-)

It is a reasonable amount of work to read the man pages and so on, but I
found it was well worth the trouble. Now when I read an ebuild I
understand what I'm seeing, before it was just meaningless stuff.

Am I correct in saying you plan to emerge mplayer with a few extra
params and not much else customizing? In that case the mods you will
make are simple and need to be done just once. Then paste the same
changes into a new ebuild each time you want to upgrade

> > 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.

Interesting. I must find out more :-)

> 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?

Just a safety net really, in case you one day forget and run 'emerge
mplayer'. Not necessary for operation :-)



--
Alan McKinnon
alan dot mckinnon at gmail dot com
--
gentoo-user@lists.gentoo.org mailing list

On Tue, 8 Jan 2008 20:23:58 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On Tuesday 08 January 2008, Daniel Iliev wrote:
> > On Tue, 8 Jan 2008 15:11:09 +0200
--snip--
> Am I correct in saying you plan to emerge mplayer with a few extra
> params and not much else customizing? In that case the mods you will
> make are simple and need to be done just once. Then paste the same
> changes into a new ebuild each time you want to upgrade
>

Actually the changes I want to make are not so few. The whole story is
that several days ago a friend of mine pointed me to a very cool
front-end for mplayer: http://smplayer.sourceforge.net/
Unfortunately it can't be found in portage yet.

Since it works with the "plain" mplayer I decided to get rid of the GUI
part (gmplayer). The USE flag "-gtk" disables the GUI, but smplayer
couldn't work with the produced mplayer. When I compiled mplayer
manually with "--disable-gui", smplayer worked just fine.
Additionally I started playing around with the src and found that on my
system mplayer can hold any optimisation I force upon it and there are
no problems.
I have best results when it's compiled with "--enable-sse2" and no
other mxx, 3dnow etc. stuff. This way mplayer produces:
"CPUflags: MMX: 0 MMX2: 0 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 1"
in the output.

Additionally I forced some gcc options on the source like this:

find . -type f -exec sed -i 's/ -O. //g; {} +
find . -type f -exec sed -i 's/-mtune=w*//g' {} +
find . -type f -exec sed -i 's/-mcpu=w*//g' {} +
find . -type f -exec sed -i 's/march=w*/march=athlon64 -msse3
-mfpmath=sse -O3 -pipe -fomit-frame-pointer/g' {} +

// Yes, it's brutal and it's a miracle that it works but what do I have
to loose? The worst case scenario is that I end up with broken src and
have to extract it again //

Now mplayer uses up to 20% less CPU which in my case is not
meaningless.

The only problem is to make portage forget about this package until the
next version is released. I thought package.provided is for this
purpose, but it doesn't work here as I expected.



> > 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.
>
> Interesting. I must find out more :-)


It's very handy. For example I don't need the innodb engine of mysql,
so my /etc/portage/bashrc reads:

==

case "$CATEGORY/$PN" in

dev-db/mysql)

EXTRA_ECONF="--enable-local-infile --without-innodb"
;;

esac

==

Unfortunately I couldn't manage to use it for solving the current
problem.


--
Best regards,
Daniel
--
gentoo-user@lists.gentoo.org mailing list

On Tue, 8 Jan 2008 14:35:27 +0200
Daniel Iliev <daniel.iliev@gmail.com> wrote:

> Hi,
>
> I want to compile mplayer in a way not supported by the ebuild and use
> portage only to keep record of the files installed in system for
> future uninstallation.
>
> The system amd64 stable.
>
> I have done the following:
>
> (1) echo media-video/mplayer >> /etc/portage/package.keywords
>
> // "emerge -p mplayer" now gives:
> media-video/mplayer-1.0_rc2_p24929-r2 //
>
> (2) echo media-video/mplayer-1.0_rc2_p24929-r2
> >> /etc/portage/package.provided
>
> (3) ebuild `equery w mplayer` unpack
>
> (4) cd $PORTAGE_TMPDIR/portage/media-video/mplayer-*/work/mplayer*
> (5) ./configure --the-way-I-want-it-to-be
> (6)make
> (7) cd ../../
> (8) touch .compiled
> (9) ebuild `equery w mplayer` merge
>
>
> Everything seems to be OK until I try "emerge -DuNav world". After
> this point portage wants to rebuild mplayer, showing all USE flags
> as newly added (e.g. "alsa%"). I expected putting mplayer
> into /etc/portage/package.keywords to make portage ignore this
> package.
>
> Where is my mistake and what is the correct method I should follow?
>

Pretty sure package.provided is /etc/portage/profile/package.provided

--
Ken69267

On January 8, 2008, Daniel Iliev wrote:
> On Tue, 8 Jan 2008 20:23:58 +0200
>
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > On Tuesday 08 January 2008, Daniel Iliev wrote:
> > > On Tue, 8 Jan 2008 15:11:09 +0200
>
> --snip--
>
> > Am I correct in saying you plan to emerge mplayer with a few extra
> > params and not much else customizing? In that case the mods you will
> > make are simple and need to be done just once. Then paste the same
> > changes into a new ebuild each time you want to upgrade
>
> Actually the changes I want to make are not so few. The whole story is
> that several days ago a friend of mine pointed me to a very cool
> front-end for mplayer: http://smplayer.sourceforge.net/
> Unfortunately it can't be found in portage yet.

http://smplayer.wiki.sourceforge.net/Contributed+Packages

lists Berkano Overlay as a source for ebuild. You might want to check it out
before you go too far building your own

--
Dmitry Makovey
Web Systems Administrator
Athabasca University
(780) 675-6245

On Tue, 8 Jan 2008 14:35:27 +0200, Daniel Iliev wrote:

> (1) echo media-video/mplayer >> /etc/portage/package.keywords

This just causes portage to use the testing, ~arch version of the program

> (2) echo media-video/mplayer-1.0_rc2_p24929-r2
> >> /etc/portage/package.provided

This should be /etc/portage/profile/package.provided

man portage explains the location and function of these files.


--
Neil Bothwick

Crayons can take you more places than starships. * Guinan

On Tue, 8 Jan 2008 23:20:02 +0200, Daniel Iliev wrote:

> Actually the changes I want to make are not so few. The whole story is
> that several days ago a friend of mine pointed me to a very cool
> front-end for mplayer: http://smplayer.sourceforge.net/
> Unfortunately it can't be found in portage yet.

http://bugs.gentoo.org/show_bug.cgi?id=176211

--
Neil Bothwick

Why isn't phonetically spelled that way?

On Tue, 8 Jan 2008 21:53:54 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

>
> > (2) echo media-video/mplayer-1.0_rc2_p24929-r2
> > >> /etc/portage/package.provided
>
> This should be /etc/portage/profile/package.provided
>
> man portage explains the location and function of these files.
>
>


That was it. Obviously I've read what I had expected to see instead of
what is really written. Now I get e big fat warning from emerge and
all works as expected:

===

WARNING: A requested package will not be merged because it is listed in
package.provided:

media-video/mplayer pulled in by 'world'

This problem can be solved in one of the following ways:

A) Use emaint to clean offending packages from world (if not
installed).
B) Uninstall offending packages (cleans them from world).
C) Remove offending entries from package.provided.

The best course of action depends on the reason that an offending
package.provided entry exists.
===


Perfect! Thanks guys!

--
Best regards,
Daniel
--
gentoo-user@lists.gentoo.org mailing list