[arch-dev-public] Mplayer in two separate packages
There is an old feature request for mplayer [1]: create it using two separate packages, one with only the CLI version and one for the GUI. There are some reasons for this: 1) By default the GUI is not enabled on mplayer 2) The package will not depend on gtk2 3) The user will be able to choose which GUI he wants to use. Now gmplayer is installed, even when the user wants to use another GUI, or do not use a GUI at all. Obviously there are some points that need to be discussed: 1) We do not usually split packages. Maybe this case is not a real division of packages because, by default, the GUI is not compiled. Don't know. 2) What do we do with the GUI version? Keep it on [extra] or move to community/AUR? I would like to hear your opinions. [1] http://bugs.archlinux.org/task/10220 [2] http://aur.archlinux.org/packages.php?ID=18516 -- Hugo
Hugo Doria schrieb:
There is an old feature request for mplayer [1]: create it using two separate packages, one with only the CLI version and one for the GUI.
There are some reasons for this:
1) By default the GUI is not enabled on mplayer 2) The package will not depend on gtk2 3) The user will be able to choose which GUI he wants to use. Now gmplayer is installed, even when the user wants to use another GUI, or do not use a GUI at all.
Obviously there are some points that need to be discussed:
1) We do not usually split packages. Maybe this case is not a real division of packages because, by default, the GUI is not compiled. Don't know.
This is the exact reason why I always refused to do that: The mplayer team encourages to generate one package with and one without the GUI, but their build system suggests the opposite: You can not split mplayer into a CLI and a GUI part. If you enable the GUI, it is compiled into one binary with all the other mplayer code. Having the same code in the repo twice and having to recompile it twice on each change is stupid IMO. If the mplayer peeps want us to separate this into two packages, I want them to separate the player and the GUI into two binaries which don't duplicate code. My vote is: Keep one package. I'd prefer the one without GUI, but I don't care.
2) What do we do with the GUI version? Keep it on [extra] or move to community/AUR?
I got you point of view. If we are going to stay with one single package i think we should have a no-gui version. This way we will be using upstream's default. Also, we have smplayer for those who wants a GUI and ABS/AUR for those who wants to enable a GUI version in the mplayer package. Lets see what the others devs thinks about this. -- Hugo
Am Samstag, 18. April 2009 19:06:52 schrieb Hugo Doria:
Also, we have smplayer for those who wants a GUI and ABS/AUR for those who wants to enable a GUI version in the mplayer package.
Lets see what the others devs thinks about this.
Nice, everything in one big binary... Just disable the gtk gui then. Those who really want to use gmplayer will find a solution and put it into AUR. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
2009/4/18 Pierre Schmitz <pierre@archlinux.de>:
Just disable the gtk gui then. Those who really want to use gmplayer will find a solution and put it into AUR.
Personally I don't use gmplayer, mplayer is enough. +1 for this. -- Andrea `BaSh` Scarpino Arch Linux Developer
On Sat, Apr 18, 2009 at 1:25 PM, Andrea Scarpino <andrea@archlinux.org> wrote:
2009/4/18 Pierre Schmitz <pierre@archlinux.de>:
Just disable the gtk gui then. Those who really want to use gmplayer will find a solution and put it into AUR.
Personally I don't use gmplayer, mplayer is enough. +1 for this.
-- Andrea `BaSh` Scarpino Arch Linux Developer
I don't use the gui either so removing it is fine with me. A TU might be willing to put an mplayer GUI package in community. BTW, I've started to work on an ffmpeg/x264 update that will necessitate an mplayer rebuild. If we get a decision (it seems that it will be removing the GUI) soon, I could implement it when rebuilding mplayer. As I would like to do the rebuild this week-end, there might not be enough time to reach a decision.
disabling the GUI, might be the best idea, I use the mplayer-nogui-svn package in AUR. So there you go, since I use smplayer. It would be better have it this way, because the original GUI of mplayer is ugly, and not that usable, the front ends are much better and advanced.
Hugo Doria wrote:
There is an old feature request for mplayer [1]: create it using two separate packages, one with only the CLI version and one for the GUI.
There are some reasons for this:
1) By default the GUI is not enabled on mplayer 2) The package will not depend on gtk2 3) The user will be able to choose which GUI he wants to use. Now gmplayer is installed, even when the user wants to use another GUI, or do not use a GUI at all.
Obviously there are some points that need to be discussed:
1) We do not usually split packages. Maybe this case is not a real division of packages because, by default, the GUI is not compiled. Don't know. 2) What do we do with the GUI version? Keep it on [extra] or move to community/AUR?
I would like to hear your opinions.
[1] http://bugs.archlinux.org/task/10220 [2] http://aur.archlinux.org/packages.php?ID=18516
Given we have smplayer and gnome-mplayer for frontends in the repos, I have no real issues with this (although I do use gmplayer when launching podcasts graphically from gpodder). Saying that, gtk2 is on ~98% of machines (according to pkgstats), so what is actually being gained here? From memory, the binary size increase is neglibale and we are adding a dep the everybody probably has anyway. I always thought this was a fairly stupid request... Allan
Anyone else? I really want to end this. -- Hugo
On Wed, Apr 22, 2009 at 9:07 AM, Hugo Doria <hugodoria@gmail.com> wrote:
Anyone else? I really want to end this.
-- Hugo
My opinion is the same as it was in that bug. I think our mplayer packages should only be mplayer, not gmplayer. That doesn't necessarily mean someone needs to package gmplayer, but I'm sure someone would. My vote - kill off the gui version in our package
On Wednesday 22 April 2009 11:22:01 am Aaron Griffin wrote:
On Wed, Apr 22, 2009 at 9:07 AM, Hugo Doria <hugodoria@gmail.com> wrote:
Anyone else? I really want to end this.
-- Hugo
My opinion is the same as it was in that bug. I think our mplayer packages should only be mplayer, not gmplayer. That doesn't necessarily mean someone needs to package gmplayer, but I'm sure someone would.
My vote - kill off the gui version in our package I completely agree with this. So please, go this way.
On Wed, Apr 22, 2009 at 11:22, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Apr 22, 2009 at 9:07 AM, Hugo Doria <hugodoria@gmail.com> wrote:
Anyone else? I really want to end this.
-- Hugo
My opinion is the same as it was in that bug. I think our mplayer packages should only be mplayer, not gmplayer. That doesn't necessarily mean someone needs to package gmplayer, but I'm sure someone would.
My vote - kill off the gui version in our package
+1
On Wed, Apr 22, 2009 at 2:04 PM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Apr 22, 2009 at 11:22, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Apr 22, 2009 at 9:07 AM, Hugo Doria <hugodoria@gmail.com> wrote:
Anyone else? I really want to end this.
-- Hugo
My opinion is the same as it was in that bug. I think our mplayer packages should only be mplayer, not gmplayer. That doesn't necessarily mean someone needs to package gmplayer, but I'm sure someone would.
My vote - kill off the gui version in our package
+1
And, let's face it, the gmplayer UI is terrible. :)
Oh no. There will be another "ArchLinux revolts against" thread somewhere. I am sure that are some people calling us "ArchLinux against the machine" already. I am building mplayer without his horrible UI already. ;D -- Hugo
On Wed, Apr 22, 2009 at 3:18 PM, Hugo Doria <hugodoria@gmail.com> wrote:
Oh no. There will be another "ArchLinux revolts against" thread somewhere. I am sure that are some people calling us "ArchLinux against the machine" already.
I am building mplayer without his horrible UI already. ;D
-- Hugo
Note that there is an mplayer in testing for the x264 rebuild. You might want to only remove the gui in the testing package. That'll be less work for you.
There is a mplayer 29188-1, without the gui, on [testing] now. Enjoy. :) -- Hugo
Am Donnerstag, 23. April 2009 14:20:41 schrieb Hugo Doria:
There is a mplayer 29188-1, without the gui, on [testing] now. Enjoy. :)
-- Hugo
It does not complie on x86_64: subreader.o: In function `sub_fribidi': subreader.c:(.text+0x2066): undefined reference to `fribidi_set_mirroring' subreader.c:(.text+0x206d): undefined reference to `fribidi_set_reorder_nsm' subreader.c:(.text+0x208d): undefined reference to `fribidi_parse_charset' subreader.c:(.text+0x20d6): undefined reference to `fribidi_charset_to_unicode' subreader.c:(.text+0x211c): undefined reference to `fribidi_log2vis' subreader.c:(.text+0x2138): undefined reference to `fribidi_remove_bidi_marks' subreader.c:(.text+0x2175): undefined reference to `fribidi_unicode_to_charset' subreader.c:(.text+0x21d6): undefined reference to `fribidi_parse_charset' collect2: ld returned 1 exit status -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Pierre, Can you try to build it without these options: --extra-cflags="-I/usr/lib/live-media" --disable-nemesi Also, can you check your fribidi version? Can someone else try to build on x86_64 to confirm this problem? -- Hugo
On Thursday 23 April 2009 09:34:15 pm Hugo Doria wrote:
Pierre,
Can you try to build it without these options:
--extra-cflags="-I/usr/lib/live-media" --disable-nemesi
Also, can you check your fribidi version?
Can someone else try to build on x86_64 to confirm this problem?
-- Hugo Confirmed, it does not build, even with your suggestions above. -- Thanks,
Eduardo "kensai" Romero
With --disable-fribidi (instead of --enable-fribidi) it's building fine, right? This seems to be related to fribidi and its a x86_64 specific problem. I am trying to find a solution but, for now, we could just disable fribidi. -- Hugo
On Friday 24 April 2009 07:25:04 am Hugo Doria wrote:
With --disable-fribidi (instead of --enable-fribidi) it's building fine, right?
This seems to be related to fribidi and its a x86_64 specific problem. I am trying to find a solution but, for now, we could just disable fribidi.
-- Hugo OK, compiled now, with disabled fribidi, sent to testing already. -- Thanks,
Eduardo "kensai" Romero
Hugo Doria schrieb:
With --disable-fribidi (instead of --enable-fribidi) it's building fine, right?
This seems to be related to fribidi and its a x86_64 specific problem. I am trying to find a solution but, for now, we could just disable fribidi.
No, it is not. This is mplayer's brain-dead, stupid and completely unlogical buildsystem. This is how the logic works in autotools: ./configure Feature foo is enabled if all necessary libraries are detected and disabled otherwise. ./configure --enable-foo Feature foo is always enabled, if some libraries are missing, configure bails out with an error. ./configure --disable-foo No tests are run for the feature foo, it is always disabled. Now, the mplayer configure applies a different, badly documented and brain-dead logic to the --enable-foo case: ./configure --enable-foo Feature foo is always enabled and all tests for necessary libraries are skipped. Furthermore, no -L, -l and -I flags are added to gcc that would be necessary to compile feature foo. It is expected that the user adds those flags to the Makefile himself (but it is completely undocumented WHERE they should be added). This means that if --enable-foo requires any additional compiler flags, using it essentially breaks the whole build process. Some people on the mplayer team seem to think this is a good idea, but it is actually counter-intuitive and unhelpful for distribution packages. If you want to actually --enable-fribidi, you can do so by NOT adding any configure flag. If you are not building in a clean chroot, then you have to add --disable-foo flags for all features you want to disable. And there is no way to make sure a feature was actually enabled, unless you carefully check the full output of configure.
Uow! This explains a lot.
From the configure script we have:
--./configure --help | grep fribidi --enable-fribidi enable the FriBiDi libs [autodetect] Then i think that we can remove the --enable-fribidi option. Can a x86_64 owner test it? -- Hugo
Hugo Doria schrieb:
Uow! This explains a lot.
From the configure script we have:
--./configure --help | grep fribidi --enable-fribidi enable the FriBiDi libs [autodetect]
Then i think that we can remove the --enable-fribidi option. Can a x86_64 owner test it?
It doesn't explain why it worked on i686, but there might be some weirdness we are not seeing. You probably want to remove most --enable-feature flags from mplayer's configure line (some of them behave differently, but you should remove all that are autodetected).
fribidi was updated this week. After that, mplayer does not compile anymore on x86_64. Giovanni, as fribidi's maintainer do you know what can be wrong? -- Hugo
Hugo Doria wrote:
There is a mplayer 29188-1, without the gui, on [testing] now. Enjoy. :)
Does this really still need the gtk2 dep? I thought the whole point of getting rid of the GUI was to remove that dep... Allan
participants (10)
-
Aaron Griffin
-
Allan McRae
-
Andrea Scarpino
-
Daenyth Blank
-
Eduardo Romero
-
Eric Bélanger
-
Firmicus
-
Hugo Doria
-
Pierre Schmitz
-
Thomas Bächler