Subject: Re: mplayer & qt?
To: None <pkgsrc-users@netbsd.org>
From: Martin S. Weber <Ephaeton@gmx.net>
List: pkgsrc-users
Date: 09/18/2006 22:56:44
Moin...
On Mon, Sep 18, 2006 at 10:43:43PM +0200, Joerg Sonnenberger wrote:
> On Mon, Sep 18, 2006 at 10:22:26PM +0200, Martin S. Weber wrote:
> > pkgsrc doesn't have "flavours" (obsd). Well. But we have gmplayer,
> > mplayer, kmplayer. Can't we deliver to users what they expect? (mplayer
> > is a standalone package; gmplayer is a "gnome" 'mplayer' package, kmplayer
> > is a "kde" 'mplayer' package.)
>
> Fine, set the options and be done. THAT'S WHAT THEY ARE USEFUL FOR.
> Yes, we currently don't have multiple option sets as binary packages
> (with a few examples like firefox-gtk1 vs firefox), but that doesn't
> mean that you can't alter the dependency list to better match your
> habits. My personal list is
> PKG_OPTIONS.mplayer= -nas -aalib -arts -esound \
> -mplayer-runtime-cpudetection -sdl
> but others have different needs and I won't force it down their throats.
Sure, but these your options wonderfully document the "roccoco" state of
the mplayer package. "BSD ain't roccoco"! *that* is what is disturbing me.
Oh fine, 10% of our packages have some options which obviously some heavy-
-weight pkgsrc commiters think are **** because of binary compatibility...
But these options shouldn't be used to turn off unneeded options (e.g. imo
-inet6 should be default! [we're not in PATRIOT2008 yet!]) but to turn *on*
personally preferred options (like building an mplayer which uses a sound
backend which is used by the kde desktop environment).
When you're breaking binary packages, break them with *additional* features
not with *lacking* features.
Regards,
-Martin