Arch Linux

I second this. I think it's a good idea.

$ ls -lhF /usr/bin/*mplayer*
lrwxrwxrwx 1 root root 7 Feb 26 15:23 /usr/bin/gmplayer -> mplayer*
-rwxr-xr-x 1 root root 9.6M Feb 26 15:23 /usr/bin/mplayer*

So what was it you wanted? A package that only contains a symlink?

No, I think they want a package without gtk2 dependencies. Maybe there is some configure option to disable the gui.

Well... I'm one of the people who use GUI that comes with MPlayer (because I hate to install additional packages for GUI), but anyway. ;)

If you decided to go through with this, I suggest we create a new package for console-only MPlayer instead of modify the default one, similar on how there's are vanilla conky package and conly-cli package.

In my humble opinion, the package with the default configuration should be the 'default' one in our main repositories, while the modified package, in this case a command-line only MPlayer, should be made into a new separate package.

http://aur.archlinux.org/packages.php?ID=16102 something similar to this i assume.
also see http://bbs.archlinux.org/viewtopic.php?id=47311

actually, the default configure option is without gui(the arch package has the --enable-gui option), I think that the best would be a mplayer package without gui and a gmplayer package with gui(I don't know how easy would be to make a package only with the gui part, it could be done even as a completely separate package which conflicts with mplayer and the other way around), but I'm not the one to decide if it compensates the work.

In Debian and Ubuntu, for example, there two packages of mplayer: mplayer (with GUI) and mplayer-nogui (without GUI).

So, maybe the solution is create a mplayer package without GUI.

Like this: http://aur.archlinux.org/packages.php?ID=16102

Thomas Bächler (brain0)

I want a package without gtk2 dependencies and default GUI.

I would prefer a mplayer and gmplayer package. This way packages which depend on mplayer don't need to be changed.

+1 to mplayer + gmplayer

So, vote, please.

+1 to mplayer + gmplayer

+1 from me.

+1 to mplayer + gmplayer

Stop +1'ing this. Use the add vote link on top. This is not a contest/poll/whatever

+1 vote.

How to vote?

Use the "add vote" link at the top, next to "Votes" in the description.

If the default config is w/o GUI, I think the Arch's vanilla software "policy" would support this. Just another 2c

Even though the creation of this request sort of was my idea i am now turning against it for various reasons some of which are:
1) I hate splitted packages.
2) MPlayer in extra already provides an mplayer executable without the GUI
3) More uneeded packaging load on developers.
4) A no gui version is part of AUR. With AUR being an alive and well part of Archlinux users can install that one if they want to skip the gtk2 dependency
5) The way this feature request evolved.

My sugestion is: dont' ship gmplayer at all in official repo (simply turn off that part of configuration), because 1. it's buggy, it doesn't recognize the right path under gnome if there are some foreign charactors in file name, which means you can't get mplayer to play if you double-click the file as usual; 2. a few people uses it, there are more elegant GUIs to use. Move gmplayer to AUR instead.

From ./configure --help
--enable-gui enable GMPlayer compilation (GTK+ GUI) [disable]

The default is for gui to be disabled. Few people use the gui as far as
I've heard.

I say build mplayer with a config that is as close to the default as is
reasonable. If the gui is disabled by default, build without the gui.

Only provide one mplayer package. If someone wants some special config
options let them build via ABS. Cheers!

If the number of packages is the problem, I second louipc's suggestion. Have only ONE package in the official repo which is NOT built with GUI support, and let everyone build w/ GUI for themselves.

That's how links browser in the official repo is compiled, for example, w/o graphics support, and if you want graphics, you can use a package from AUR or do it yourself using ABS.

Thing is that the package already in extra provides mplayer. If it is replaced by a package built without gui, the only thing you gain is getting rid of the gtk2 dependency. Is that worth it? IMO its not. Also you cant really count how many users actually use the GUI.

But that's already two packages. IMHO, it's far better to have one package, and let users customize it, rather than provide customizations for everything. But that's my opinion. At least for me, that'd be more Arch Way-ish. I have a few other packages that do require gtk, so I'm not too unhappy about mplayer requiring the same.

It's the arch way to compile binary packages with vanilla options, isn'it it? GUI people should customize their mplayer through ABS or get mplayer-whatever from AUR. That's how it is with every other package, right?

If the vanilla way you are referring to means compiling ALL packages with configure --prefix=/usr make make install, even though its close, no it is not the Arch way. Packages still need to have features enabled. Also the Arch way is not the anti-GUI way. The "GUI people" you are talking about can easily say what i said before:
4) A no gui version is part of AUR. With AUR being an alive and well part of Archlinux users can install that one if they want to skip the gtk2 dependency
BTW since i forgot to write it above, this request is for having 2 seperate packages in the repos and the 20 users have voted to have that, NOT just 1 mplayer package that doesnt provide a GUI.

For me, the Arch Way is to add features you want, not subtract the ones you don't.

Of course it's nice to have features enabled. But this is one feature
that I believe is hardly used and it pulls in a whole toolkit.
I've tried the GUI. It's really not worth looking at. Anyone that I've
talked to seems to agree.

There's one comment asking to keep the GUI but also admitting
that the package should be built with defaults (no GUI).

Anyways packages should be built as close to default as is reasonable.
I think the consensus here is to remove the mplayer GUI.

Actually I'm thinking the same number of people that are inconvenienced
by the GTK dependency are about the same number of people that actually
use the GUI. In this case I would side with defaults, and removing the
GUI.

Maybe we should do test and see how mplayer built with GUI reacts when
GTK is missing. If it fails then remove GUI. If not, then leave it and
put GTK as a makedepends and optdepends.

Alright I just tested. Mplayer certainly does fail if you
simply remove GTK.

I say remove the GUI. Mplayer is geared towards the
command-line terminal user, not the point and click user.

I'll remove the GUI from mplayer-svn on the next update. brain0 can decide about the extra/mplayer package.

I don't understand. if we split MPlayer package into 2 packages like Kramer original requested, then people who don't use the default GUI get what they want, a MPlayer package that doesn't depends on gtk and another one that have GUI enabled for people who wish to use the GUI (trust me, there are people who use the default GUI, I'm one of them). It's a win-win situation. There's no need to have only "one" MPlayer package in official repositories.

People who want a GUI can use Pymp or another frontent. Or, for that matter, just tell their file manager to open stuff with mplayer --whateveroptions, and do the usual point and click routine.

Is it really that bad to have two MPlayer packages, one with GUI disable and another one with GUI enable?

Also, like dolby said, isn't this bug report about requesting MPlayer package to be split into two packages? Why have it turns into "let's disable MPlayer default GUI"?

If the GUI itself could be packaged seperately that would be ideal, but I don't think mplayer likes being split.

Is it really that bad to have two MPlayer packages, one with GUI disable and another one with GUI enable?

Also, like dolby said, isn't this bug report about requesting MPlayer package to be split into two packages? Why have it turns into "let's disable MPlayer default GUI"?

Ouch! Duplicated. Please delete my above comment (and this one too).

Following the "enable GUI" logic, we could easily ask for 4 or 10 packages each addressing a specific combination of build-time options. IMHO there is absolutely no point in that since we can easily modify any default setting using ABS.

That same logic can also be apply to the non-GUI position. It is just as easily to use ABS to disable MPlayer's GUI, so why the need to 'modify' MPlayer package, then?

The problem here is MPlayer have been compiled with GUI enabled for so long. Having only one MPlayer package with disable-GUI option is the equivalent of stripping a feature from a package for... what reason? It will also effect other package in the official repositories. For example, what will happens to mplayer-skins package? Will it have to be remove or move to communities/AUR?

Also, replace the current MPlayer with the new one without GUI will causes problem for users who are currently using the GUI, again for what reason? Do we really need to have users complaining on the forum/bug tracker that their (g)MPlayer package didn't work after upgrade?

Again, this bug report is about splitting MPlayer into 2 packages that will provide the same functionalities for all users as the old one, not having one with stripped down functionalities for no good reason. I'm sure a lot of people who voted for this bug are not doing so because they wish to have only one MPlayer package.

"That same logic can also be apply to the non-GUI position."

Yes. So should I file a report asking for links browser with graphics enabled by default? No. Why? Because graphics are disabled _by default_ in the upstream sources. I will not whine because of that, because I know how I can enable graphics (or anything else I need using ABS). I prefer vanilla packages regardless of whether they are directly usable to me or I have to tweak them.

I personally think it's overkill to have TWO packages for the SAME software, so I think it should be one that's as close to upstream defaults as practical.

"Again, this bug report is about splitting MPlayer into 2 packages that will provide the same functionalities for all users as the old one"

Not quite. The main point of the original report was this:

* Default mplayer package without GUI called mplayer
* Secondary mplayer package with GUI called gmplayer, mplayer-gui or whatever

It's not just about splitting, but also about what should be considered the default. If Arch says it distributes vanilla packages (or as close to vanilla as possible, which is exactly what I've been told when I started using Arch), then it's logical to expect an user to get the same thing that is present on upstream servers, just compiled to work on Arch. If the upstream default is no GUI, then I prefer no GUI and manual tweaking with ABS, rather than having the devs tweak the packages for me (other than making them work in the first place, of course).

Just to clarify, even though I personally didn't like the idea, I have absolutely _no_ problem with having disabled-GUI MPlayer package as the default one, as long as we have another MPlayer package that have GUI enabled in the repositories for users that needs them.

Is it overkill to have 2 slightly different MPlayer packages? I personally don't think so, but I leave the final decision to the maintainer.

IMHO, I prefers that we didn't breaks MPlayer for people who currently use the default GUI (the people who didn't use the GUI won't be effected by the change anyway), and this is why I insisted that there should be two MPlayer packages.

I think this is a waste of time.
If I don't want the gui, I can use ABS and build my own package.

The Arch Way: "a lightweight base structure without unnecessary additions, modifications"

- GUI option *modified* from default
- gtk2 dependency *added* to mplayer
- skin file *added* to mplayer

Is this really a waste of time? There is a limit to how vanilla you should be, but it makes sense to change the default extra/mplayer package to one that doesn't have GUI enabled as per upstream default.

How long can take to make a decision about this?

Remember GUI is not default in MPlayer. So, a hope, mplayer without gui for default.

It will take as long as it takes. Just because this was filed with high severity does not actually make it so...

Has anyone actually made the split packages for mplayer and gmplayer and posted the PKGBUILDs here? Is that even possible or do we need an mplayer and a mplayer-gui package that conflict each other? Anyone actually done the research on this?

"It will take as long as it takes."

And since this is a request, IF it takes.
TomK has stated already that next mplayer-svn build (made by him) will have no GUI, but IIRC never commented on having a gmplayer-svn too..
Brain0 still hasnt responded.

As long as I remember, archlinux mplayer package was build with the gui.
It's a feature. This is not perfect but it works and I know 2 people here who use it.
If you want to build a desktop without gtk, sync ABS, remove -enable-gui and install it.
You can also get a pkgbuild from AUR: http://aur.archlinux.org/packages.php?ID=18078

I'm pretty sure we can't build two package that will not conflict.
Kiss also mean "do it yourself"...

The GUI is bad. Really. It's ugly as hell. It displays every damn error message (i.e. a lot of them) in a pop-up window. It doesn't let you dynamically resize videos. It auto-associates itself with every video file. In a word, it sucks.

I don't see why it should be included with everything that uses MPlayer.

Hmm, it looks like the mplayer packages in the repo are currently unmaintained. What's going on?

Stop just commenting in the bug report for the sake of commenting. This bug report would be more effective with 40 less useless comments which are required to be read on the off chance something is important. More signal, less noise!

After a bit of googling this (seems to be how the devs of mplayer want it packaged) turned up:
http://www.mplayerhq.hu/DOCS/tech/binary-packaging.txt

However, Arch doesn't have a history of split packages, that too splitting mplayer
just because of a single dependency of gtk2 seems silly to me. It is possible though
to make split packages so that the package for gmplayer depends on mplayer. The trick
is simply removing all the common files from the gmplayer package (which otherwise
is the same as the mplayer package only compiled with the --enable-gui option). Also
since a single mplayer binary must be either compiled *with* or *without* GTK2, there
can't be a symlink from gmplayer to mplayer, like in the present case. Thus there needs
to be then two binaries gmplayer and mplayer separately. I've attached the two PKGBUILDs
below. This solution is very hackish though (the total size requirement
of gmplayer and mplayer package goes up to ~13MiB instead of the current 8.3MiB because of
the duplication of the binary, also the package needs to be compiled twice, wasting time).

I've tested the packages by building on my machine (i686) and it works fine here.

I noticed that Debian does not have a separate mplayer-nogui, though Ubuntu has. Ubuntu's
mplayer-nogui also cannot coexist with mplayer (there's a Provides relation).

Maybe we could file this upstream. We could ask mplayer people to separate code into smaller packages or libs. Then we could have mplayer-essential which would provide stuff for two SEPARATE front ends mplayer-cli and mplayer-gui.

Sorry if this is obsolete revival.

I would add the splitting of mencoder to a separate package also, so frontends to it can depend directly on mencoder and not the whole mplayer (now with GUI) package. Right now if someone wants to package a QT frontend to mencoder it will depend on the GTK kit for the GUI part of mplayer, sounds no-good to me, I came from the debian world ;), sorry for my poor english.

That can be solved by listing GTK as an optional dependency for mplayer.

Glenn, but what happens, if the user installed Gtk and then MPlayer? Maybe the dependency for MPlayer is optional, but there is no need for pcman to suggest Gtk, if it’s already installed.

MPlayer and GMPlayer totally should be seperated.

@Dirk: where lies the problem in pacman suggesting GTK as an optional dependency? That how optdepends work in pacman. Pacman won't install optdepends, it will merely output a message saying that GTK is an optdepend.

@Glenn: I’m not sure, if i got you right. What will happen, if the user installs MPlayer while having GTK installed already?

For me it’s not about having to install GTK if installing MPlayer, it’s about starting MPlayer without GUI. When setting a MIME aware application to start video files with MPlayer, it should be MPlayer and not GMPlayer.

What we (i) need is: two *.desktop-files. One saying “MPlayer”, that starts MPlayer in no-GUI mode (video window only) and one saying “GMPlayer” and starting MPlayer in GUI mode (video window and controls).

Additionally changing MPlayer’s dependencies and making GTK optional for MPlayer would be good for systems used without GTK.

I really think that mplayer package should be splitted in 3 packages:

* mplayer (without GUI)
* gmplayer (mplayer with default gui)
* mencoder

(if it fits your taste the two main packages can be renamed to mplayer (with default GUI) and mplayer-cli)

The main reason for my proposal is that mplayer "full" package has some pretty different dependencies, And always yoy end installing extra packages that you don't really need.

So for example, if I would try to install an gtk frontend to mplayer, that will pull the extra files of the default GUI shipped with mplayer, that's not so bad, but now think that i'm running KDE and i'm going to install a QT frontend for mplayer, that will pull me all the deps to run the default interface of mplayer, including the GTK kit!

So, to address deps problems my proposal is this:

* All mplayer frontends sould depend (on mplayer / mplayer-nogui depending on the opted scheme)
* All mencoder frontends should depend on mencoder (as this packages doesn't depens on it only pulls the correct depencencies)

Also when installing mplayer (any version) you dot't have to pull the deps for mencoder (a package and deps that maybe you'll never use)

The good thing is that the half of the work is been done by SlumSlayer, he packaged mplayer without gui, but with all the things of the mplayer from extra (leaving mencoder out, keep reading) because, ke made a separated mencoder package, Ergo the work is already done:

Here are the links for the AUR packages:

mplayer-nogui: http://aur.archlinux.org/packages.php?ID=20103
mencodeer: http://aur.archlinux.org/packages.php?ID=20103

I think that packaging scheme should be adopted, and the packages by SlumSlayer had to be taken by an TU an moved to extra.

My vote goes for mplayer (cli only) in extra, gmplayer in community/unsupported

mplayer GUI (gmplayer) was removed from the package. Those who wants gmplayer will have to compile it (using ABS/AUR).