From owner-cvs-all@FreeBSD.ORG Tue Jul 26 12:13:01 2011 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C1F0106564A; Tue, 26 Jul 2011 12:13:01 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5630F8FC13; Tue, 26 Jul 2011 12:13:01 +0000 (UTC) Received: by pzk5 with SMTP id 5so2262125pzk.17 for ; Tue, 26 Jul 2011 05:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ebLippAi7+q1yBluMODea8b/KNdMSssTVeQx6oSqGXk=; b=q+HVx/NA/6zUjbcQDJCVL5/OCxB5p6z48GG4bcqPs2HjhwmhQNeXXcSuSCa+tQbTYg GpyfxxRb0g05FxxSjQ0GFkQFyZqUosqZLSimSOJVjJqAozPi1atOLv5PyOSdYWBSPfy0 7WKXDDAgKIa3e1/1CskM78CeD/xUdf68wm9MA= MIME-Version: 1.0 Received: by 10.68.35.70 with SMTP id f6mr9453152pbj.506.1311682380538; Tue, 26 Jul 2011 05:13:00 -0700 (PDT) Received: by 10.68.40.72 with HTTP; Tue, 26 Jul 2011 05:13:00 -0700 (PDT) In-Reply-To: <20110726032009.23147.qmail@exxodus.fedaykin.here> References: <201107200252.p6K2qZRb053515@repoman.freebsd.org> <4E2B2B82.1020506@FreeBSD.org> <4E2D7EEC.8030600@p6m7g8.com> <20110726025646.74097.qmail@exxodus.fedaykin.here> <20110726032009.23147.qmail@exxodus.fedaykin.here> Date: Tue, 26 Jul 2011 08:13:00 -0400 Message-ID: From: "b. f." To: Mario Sergio Fujikawa Ferreira Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , cvs-all@freebsd.org, ports-committers@freebsd.org, riggs@rrr.de, "Philip M. Gollucci" , cvs-ports@freebsd.org Subject: Re: cvs commit: ports/multimedia/mencoder Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 12:13:01 -0000 On 7/25/11, Mario Sergio Fujikawa Ferreira wrote: > On Mon, Jul 25, 2011 at 11:55:58PM -0300, Mario Sergio Fujikawa Ferreira > wrote: >> Date: Mon, 25 Jul 2011 23:56:22 -0300 >> From: Mario Sergio Fujikawa Ferreira >> To: "Philip M. Gollucci" >> Cc: Doug Barton , bf1783@gmail.com, "b. f." >> , ports-committers@FreeBSD.org, >> cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, riggs@rrr.de >> Subject: Re: cvs commit: ports/multimedia/mencoder Makefile >> User-Agent: Mutt/1.5.21 (2010-09-15) >> >> On Mon, Jul 25, 2011 at 02:33:56PM +0000, Philip M. Gollucci wrote: >> > Date: Mon, 25 Jul 2011 14:34:20 +0000 >> > From: "Philip M. Gollucci" >> > To: Doug Barton >> > CC: bf1783@gmail.com, "b. f." , Mario Sergio >> > Fujikawa Ferreira , ports-committers@FreeBSD.org, >> > cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, riggs@rrr.de >> > Subject: Re: cvs commit: ports/multimedia/mencoder Makefile >> > User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) >> > Gecko/20110507 Thunderbird/3.0.11 >> > >> > On 07/23/11 20:13, Doug Barton wrote: >> > > On 07/22/2011 23:07, b. f. wrote: >> > > >> > >> I must renew my plea to avoid these "fixes". When a user sets >> > >> WITH/WITHOUT_FOO, he means precisely "build this port >> > >> WITH/WITHOUT_FOO", and not "build this port WITH/WITHOUT_FOO, except >> > >> if package X is installed, and, if it is, silently do something >> > >> else", >> > >> and we should not be adding code to do the latter. We should instead >> > >> patch the broken distribution configure scripts and Makefiles, so >> > >> that >> > >> the problem does not occur. If a lack of time or another problem >> > >> prevents this from being done initially, then as a temporary >> > >> workaround, we should add something like: >> > >> >> > >> .if exists(${LOCALBASE}/lib/libass.so) && defined(WITHOUT_ASS) >> > >> BROKEN= libass is installed, so broken mplayer scripts will ignore >> > >> WITHOUT_ASS >> > >> .endif >> > >> >> > >> so that the user will know that his choice of options cannot be used, >> > >> and he can take the appropriate action -- and he will not be misled >> > >> into thinking that his choice of options are used when they are not. >> > > >> > > +1 >> > > >> > Yes, I agree violently too. I even remember removing about 10 >> > occurrences in the past. >> >> Okay, I agree in principle. Whatever the user decides should be >> upheld. I hate when a port disagrees with me. However, the reality >> is that mplayer configure structure is broken and we can build it >> with this. >> >> The situation is as follows for those who might not be following: >> >> --- >> A) if multimedia/libass is not installed: >> 1. mplayer/mencoder build just fine with the internal code supplied >> >> B) if multimedia/libass is installed: >> 2. mplayer/mencoder only builds if we fix configure script and >> force port dependend on multimedia/libass because mplayer's >> configure is broken. >> --- >> >> Is multimedia/libass easily available? Yeah, because multimedia/vlc >> depends on it and lots (if not most) users building mplayer, should >> have already built vlc. So this problem is pretty standard for many >> users. >> >> The suggestion I've been reading is that we mark the port as >> BROKEN? Well, then first we need to decide some other things (and >> this has been an age long discussion on the institution of ports): >> >> 1) What should be our standard policy for ports? What is the main >> reason we have ports? >> >> I believe we have ports to have applications working on FreeBSD >> out of the box with as many options as we want, not just the packaged >> standard options. We back port as much fixes as possible so that >> we don't have to keep fixing. However, the foremost reason for ports >> is having things WORKING out of the box. That's just my 2 cents. I >> know how to build-fix-tweak my way around a broken 'portupgrade -a' >> but that's not the average user .... and we also want the average >> user. >> >> Ports do not exist to teach the user. They exist to work. >> >> Maintainers and developers exist to teach each other. And, we try >> to educate the user whenever the opportunity presents itself. >> >> 2) Do we have policy exceptions on ports standards? Or, does the >> same policy apply to every single situation? >> >> We do have policy exceptions today which I will not name and we >> will keep having them because not all ports are born equal. And, >> that is that. Some ports are more important than others and they >> are entitled to special treatment (I am not making a case for >> mplayer, just making a point). >> >> >> I apologize if the email seems to be inflamatory. I read it twice >> to try working out more subtle wording but I think I couldn't. I >> apologize again. >> >> To sum up. My point is this: Is the ports system a community >> service or a user teaching ground? Do we give mplayer special >> dispensation on this or do we devise/appy a policy here? >> >> We need a middle ground: the port should uphold the user but it >> should also build if it's not too difficult. Marking it BROKEN when >> it's so easily "fixable" is too harsh a decision. >> >> Please, revert the commit if that's the overall decision. >> Nonetheless, let's keep up this thread because I still believe we >> can reach common ground. >> > > I have a simple suggestion that eluded me on my previous email > and could have prevented the rant I wrote. :( > > Let's remove the OPTIONS ASS (for libass) entry AND let's simply > depend on multimedia/libass. > > It is simple and fulfills every criteria: > > 1) port is going to build > > 2) no option will be ignored > > 3) POLA is upheld since the port was built with ASS subtitle > support before and it will continue to be. The only difference > is that it will always use an external library instead of the > internal one. > > Let me know what you think. A multimedia/mencoder patch is attached > as a suggestion. Is this compromise acceptable? This would be better than the current state of the port, but I'd prefer my earlier patch, because multimedia/libass drags in some other dependencies, among them converters/recode, which I'd rather avoid, because it has some unpatched bugs, including an overly-wide bitfield that causes builds with newer versions of gcc to fail. Again, I must ask, what makes you think that the mplayer configure script is defective? As I said earlier, I cannot reproduce the problem. Could you provide some more information? And, even if it is, what prevents us from simply patching it? Also, what about fixing the fragile piece of code that I pointed out, and the enca autodetection? With regard to your earlier comments, marking a certain choice of options as BROKEN is a temporary measure (and it isn't the same as marking a port as unconditionally BROKEN). It is preferable to fix the problem so such a measure doesn't have to be used. But in any event we should not be ignoring a user's explicit choice of options, and silently doing the opposite, just to avoid any need for user intervention. Users know that they must occasionally reconsider their choice of options with new versions of ports, as in this case. Those who don't want to think about it can just accept the defaults, or use packages. Anyway, thank you for taking the time to try to allow mplayer to work with a more recent version of libass, for those who need it. b.