Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 28846 - split media-video/mplayer to media-video/mplayer and media-video/mga_vid
Summary: split media-video/mplayer to media-video/mplayer and media-video/mga_vid
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Joel Martin (RETIRED)
Depends on: 1477 5477
  Show dependency tree
Reported: 2003-09-15 23:38 UTC by Georgi Georgiev
Modified: 2004-11-10 18:20 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---

mga_vid-1.0_pre1.ebuild (mga_vid-1.0_pre1.ebuild,804 bytes, text/plain)
2003-09-15 23:39 UTC, Georgi Georgiev
mplayer-1.0_pre1.patch (mplayer.diff,976 bytes, patch)
2003-09-15 23:41 UTC, Georgi Georgiev
Details | Diff
mplayer ebuild to put mga_vid.o in misc directory (mplayer-1.0_pre4-r2.ebuild,10.77 KB, text/plain)
2004-05-11 08:04 UTC, Joel Martin (RETIRED)
mga_vid-1.0_pre4-r4.ebuild (mga_vid-1.0_pre4-r4.ebuild,1.08 KB, text/plain)
2004-06-27 00:38 UTC, Georgi Georgiev
Makefile-2.6 (Makefile-2.6,169 bytes, text/plain)
2004-06-27 00:40 UTC, Georgi Georgiev
patch to mplayer-1.0_pre4-r7.ebuild (rebuild-mga_vid.patch,817 bytes, patch)
2004-08-21 08:13 UTC, Paul Mogren
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Georgi Georgiev 2003-09-15 23:38:51 UTC
Recompiling mplayer takes quite some time. I suggest to take the compilation of
mga_vid.o to a separate package.

The reason: recompiling the kernel would only require to recompile one, very
quick to compile package instead of the whole mplayer. Mplayer can depend on the
package if needed.
Comment 1 Georgi Georgiev 2003-09-15 23:39:52 UTC
Created attachment 17790 [details]

an ebuild for mga_vid
Comment 2 Georgi Georgiev 2003-09-15 23:41:18 UTC
Created attachment 17791 [details, diff]

A patch to the mplayer ebuild to finalize the split of mplayer and mga_vid
Comment 3 SpanKY gentoo-dev 2003-09-16 03:45:42 UTC
perhaps we could come up with a better solution ... there are many packages (like svgalib) that have kernel modules which are a small part compared to the rest of the distribution ...
Comment 4 Georgi Georgiev 2003-09-16 04:32:55 UTC
After typing for a while here, I decided to take my comment to in a search for a "better solution".
Comment 5 Martin Holzer (RETIRED) gentoo-dev 2003-11-19 10:19:41 UTC
phoenix any comment ?
Comment 6 Joel Martin (RETIRED) gentoo-dev 2004-04-01 08:09:24 UTC
What about putting it in /lib/modeuls/*/misc/ so that it doesn't get blown away
by make modules_install?
Comment 7 Joel Martin (RETIRED) gentoo-dev 2004-05-11 08:04:09 UTC
Created attachment 31184 [details]
mplayer ebuild to put mga_vid.o in misc directory

This attachment simply moves the location of the mga_vid.o module to

That should fix the original problem because when the kernel modules are
the misc directory will be left alone.

Does anybody strenously object to this solution? If not, then I will submit
change in the next few days.
Comment 8 Georgi Georgiev 2004-05-11 09:29:54 UTC
Not sure how this will help. The original problem is that when a new kernel is installed, one has to rebuild the complete mplayer package. I don't see how this would hurt either, so if you feel like -- go ahead and assign it. This would not resolve this bug though. You could mark it as INVALID or WONTFIX though.
Comment 9 Joel Martin (RETIRED) gentoo-dev 2004-05-11 09:48:56 UTC
Okay, well, that wasn't clear from the original bug request. 
"recompiling the kernel would only require..." implies to me that we are recompiling the same kernel again.

I will probably submit the changes that I made, but not close this bug.
Comment 10 Chris White (RETIRED) gentoo-dev 2004-06-26 01:13:53 UTC
Georgi Georgiev and everyone on this bug:

Ok, I was dealing with the matrox issue in another bug, and came across this.  My idea was as follows:

1) make sure that the kernel 2.6 matrox patch for 1.0_pre4-r4 works (need a matrox tester for that :).

2) if it does, a modified mplayer ebuild could be created, as I found out from the mplayer site, that technically the mga driver should be compiled first, then the mplayer code.

3) if this was the case, the matrox USE flag could encompass a separate compile process within the ebuild, leaving the intended result.

Most important is to see if all is well with 2.6 patch included in 1.0_pre4-r4.  If that works, all might be well.
Comment 11 Georgi Georgiev 2004-06-27 00:37:04 UTC
Regarding the order of compilation: it doesn't seem to matter at all.

The patch itself: It does work, though it doesn't work for udev, so devices have to be created manually. I was trying to enable udev (sysfs) support, by looking at the basic-sysfs patch for nvidia-kernel, but it didn't work. This shouldn't surprise me, since nvidia-kernel doesn't work with sysfs either.

About the ebuild: The current Makefile doesn't compile the module on a KBUILD_OUTPUT enabled kernel. I am using a separate Makefile for 2.6 compilation.
Comment 12 Georgi Georgiev 2004-06-27 00:38:23 UTC
Created attachment 34256 [details]

My mga_vid ebuild. To use as a reference for the mplayer ebuild.
Comment 13 Georgi Georgiev 2004-06-27 00:40:31 UTC
Created attachment 34257 [details]

The Makefile to compile the module. The current Makefile doesn't work when
Comment 14 Georgi Georgiev 2004-07-15 21:48:28 UTC
Comment 15 Paul Mogren 2004-08-21 08:13:30 UTC
Created attachment 37867 [details, diff]
patch to mplayer-1.0_pre4-r7.ebuild
Comment 16 Paul Mogren 2004-08-21 08:14:31 UTC
Comment on attachment 37867 [details, diff]
patch to mplayer-1.0_pre4-r7.ebuild

mplayer-1.0_pre4-r7.ebuild does not build mga_vid correctly. The ebuild does:
build mga_vid
make all  (This performs a distclean because we just configured, but then it
does not build mga_vid again.)
install  (cannot stat `mga_vid.o': No such file or directory)

Attached is a patch to the ebuild to build mga_vid again before the install
The pre5 ebuilds appear to have the same problem.
Comment 17 Chris White (RETIRED) gentoo-dev 2004-11-10 18:20:19 UTC
I've decided to remove the matrox building sections all together, but the SUPPORT for matrox in MPlayer will still be avaliable.  My main reason for doing this comes straight from the README:

                       WARNING  -----  WARNING

This code messes with your video card and your xserver. It will probably
lock up your box, format your hard drive, and cause your brand new g400
MAX to spout 6 inch flames. You have been warned.

                       WARNING  -----  WARNING

mga_vid is also a monster hack

in fact, the whole design sounds very unstable to me.  So unstable in fact, that I simply cannot support it, as it sounds like it doesn't want to be supported in the first place.  Does this mean you'll won't be able to use MPlayer with matrox support?  No, the matrox configure logic still remains, it will be up to you to compile it "at your own risk".  I'm sure this may not go down well with some people, and can already see flames comming my way, but I simply cannot support something that the authors themselves consider unstable.