On 7/26/11, b. f. <email@example.com> wrote:
> On 7/25/11, Mario Sergio Fujikawa Ferreira <firstname.lastname@example.org> 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.
So, specifically, I'm suggesting something like the attached patch,
which allows those of us who don't need libass to avoid unnecessary
and problematic dependencies, as in your original commit, but avoids
overriding user options. It sets the ASS option to be on by default,
to address your POLA concerns. It also includes fixes for the other
problems with these two ports that I mentioned, portrevision bumps,
and your tweaks for the pkgconfig dependency.
> 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?