New ebuild for mplayer has many use-flags auto-enabled (+useflag), more than previous version ebuild. Is there a rationale behind this? For example, why are fbcon and rar useflags enabled by default? Doesn't such auto-enabling kind of beats the purpose of use-flags?
I agree... now I have to add a lot of -USE flags to my /etc/portage/package.use... what's the purpose?
The reason behind enabling more was users complaining that stuff didn't work out of the box, so I turned on popular codecs as well as support for everything internal.
That seems reasonable enough.
Well, maybe it's better to display some general warning prior to merge. I think that only vital use-flags should be auto-enabled, but I'm not sure about the Gentoo policy on this matter.
(In reply to comment #4) > Well, maybe it's better to display some general warning prior to merge. emerge -pv $mplayer :) > I think > that only vital use-flags should be auto-enabled, but I'm not sure about the > Gentoo policy on this matter. Well, one man's vital is one man's irrelevant. Since mplayer is touted as the "plays it all media player", it kind of makes sense to enable as much stuff as possible by default.
I actually meant vital to functionality of the application. For example it doesn't make much sense to compile music player without any sound support. And should an application offer such possibility, "sound" use-flag should be auto-enabled. The example is hypothetical. Well, to cut story short. Could you please explain why fbcon, rar are enabled by default? And why samba is disabled (with -use) while ftp is enabled?
(In reply to comment #6) > Well, to cut story short. Could you please explain why fbcon, rar are enabled > by default? And why samba is disabled (with -use) while ftp is enabled? See comment #2. fbcon and ftp are internally supported, no external deps. Samba needs samba client installed, to do mplayer smb://filename rar is for supporting compressed subtitles
I'm still not convinced. We don't globally auto-enable png use-flag just because users complain that they can't display PNG files as they forgot to enable this use-flag, didn't read handbook or just didn't care to issue emerge -av and check the use-flags, do we? I don't see why mplayer is so special in that regard.
(In reply to comment #8) > I'm still not convinced. We don't globally auto-enable png use-flag just > because users complain that they can't display PNG files as they forgot to > enable this use-flag, didn't read handbook or just didn't care to issue emerge > -av and check the use-flags, do we? I don't see why mplayer is so special in > that regard. > I'm not going to argue semantics, especially after explaining the situation multiple times. If there are *individual* use flags you think are unnecessary to be enabled by default and can provide a reasonable argument as to why they shouldn't be, then let's take it from there. That said, I would tend to agree that some of the image ones are a bit overboard (png, jpeg, gif, pnm) as they are for encoding from / to image formats and not normally used.
> If there are *individual* use flags you think are unnecessary to be enabled by default and can provide a reasonable argument as to why they shouldn't be, then let's take it from there. Well, let's see the overall picture. This is the list of all auto-enabled flags, it's 49 of them (as of 20090226.28734): +a52 +aac +alsa +amrnb +amrwb +ass +cddb +cdio +dirac +dts +dv +dvd +dvdnav +enca +encode +faac +faad +fbcon +ftp +iconv +jpeg +live +mad +md5sum +mmx +mp2 +mp3 +nemesi +network +opengl +png +pnm +quicktime +rar +real +rtc +schroedinger +sdl +speex +theora +tremor +truetype +vorbis +X +x264 +xscreensaver +xv +xvid +xvmc Out of 104 use-flags for this package total. And there is 13 use-flags that are enabled despite not being mentioned in make.conf and package.use (effectively meaning that I don't want them). Your and other user mileage may and will vary. But I do think that about a half of flags being auto-enabled is overkill. I don't know about the Gentoo policy on auto-enabling flags, so if you as a maintainer say it's perfectly reasonable I'm forced to accept. The flags that I'm personally strongly against are: dv: For me not owning a camcoder it is redundant. fbcon: I'm not going to watch movies in console and I prefer not to keep it in mplayer binary (bloat-free is what Gentoo always was). Also I don't think it makes much sense to enable both X and fbcon use-flags. md5sum: From man page: md5sum Calculate MD5 sums of each frame and write them to a file. Supports RGB24 and YV12 colorspaces. Useful for debugging. You must agree that only a tiny fraction of users will want this. There is a bunch of other flags that I think should not be auto-enabled, but as I already enabled them in make.conf I don't think it will be fair to question them.
(In reply to comment #9) > If there are *individual* use flags you think are unnecessary to be enabled by > default and can provide a reasonable argument as to why they shouldn't be, then > let's take it from there. I should clarify --- any use flags that have *external* deps. I see no reason not to auto-enable anything internal (md5sum, dvd, dvdnav, fbcon, etc.) if it's not pulling in more dependencies.
(In reply to comment #11) > I see no reason not to auto-enable anything internal (md5sum, dvd, dvdnav, > fbcon, etc.) if it's not pulling in more dependencies. Well, the reason actually is not to include unnecessary features that increase binary size and load time. If there is no clear policy on this maybe we should take a look on other ebuilds. I'm not sure if any other ebuild has that many useflags as mplayer, but take ffmpeg, for example. Only processor optimizations (3dnow, mmx, mmxext, ssse3) and main feature of ffmpeg (encode) are auto-enabled. Reasonable? Yes. (By the way, mplayer has mmx auto-enabled, but not mmxext) Or take wine: only X and gecko flags are enabled and this is also reasonable. dev-util/git: nothing is auto-enabled. I just browsed through some of the installed packages with higher amount of use flags.
Alright, Ill look at scaling it back a bit for the next bump (which should be real soon here). One thing I'm not gonna change my mind on though is the codecs.
Thanks :) Personally I was never against codec useflags. I do enable almost all of them anyway.
(In reply to comment #11) > (In reply to comment #9) > > > If there are *individual* use flags you think are unnecessary to be enabled by > > default and can provide a reasonable argument as to why they shouldn't be, then > > let's take it from there. > > I should clarify --- any use flags that have *external* deps. > > I see no reason not to auto-enable anything internal (md5sum, dvd, dvdnav, > fbcon, etc.) if it's not pulling in more dependencies. > Although my gripe is with media-video/mplayer-1.0_rc2_p20090322 it is about this very issue and I see no reason to open a duplicate bug. In this latest version of mplayer, the vdpau USE flag has been defaulted on. This requires the newest version of the nvidia drivers (an external dependency...) that are not valid for older nvidia cards (geforce 4 in my case). You have violated your own rule by enabling by default a use flag that requires an additional external dependency that is not valid for a lot of people's systems. To make it worse, the actual error message that is displayed has nothing to do with the vdpau use flag, but tells the user that they must unmask a newer version of the nvidia drivers. I new better than to do that, as I would then not have a working X install, but the majority of users probably wouldn't.
Fixed in CVS
Why are "dirac" _and_ "schroedinger" enabled by default (p20090322)? They both should do the same thing... so one of them is enough in my opinion...
