Re: mplayer & qt?

["Martin S. Weber" <Ephaeton%gmx.net@localhost>]

Hello...

I might add that I'm a bit sarcastic, ok. But what I'm aiming at is
a general picture (see below).

On Mon, Sep 18, 2006 at 09:45:17PM +0200, Julio M. Merino Vidal wrote:
> On 9/18/06, Martin S. Weber <Ephaeton%gmx.net@localhost> wrote:
> >(...)
> >Fine. We have non-kde users who are forced qt/kde down their throat. 
> >Imagine
> >a gnome-centric user, how does she feel having forced kde down her throat?
> >(or does she use that <censored> gnome sw instead?).
> 
> It will only pull in some KDE *libraries* that won't be visible to the
> user at all.  Keep in mind that mplayer is compiled with *both* esound
> and arts support.  So if the user is running GNOME (with the sound
> daemon enabled) mplayer will default to esound.

Ok, so we put in multiple cpu hours to build something which not by
default generally is used. As an example, building "qmake" (twice,
qt-tools and qt-libs) uses (on my machine) takes like  an cpu *hour*.
[note; this is *not* building the whole package, this is just building
twice a tool that qt-x uses to build themselves].

(note 2: "visibility" = "time spent in building that")

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.)

*I* am no "desktop environment" user myself, *and* I have what is considered
a "slow" machine by nowadays standards.

What is enerving me is that my computer spends cycles spent better on other
things but building stubs for desktop environments I do no use.

Can't the kde (meta)package depend on kmplayer which builds 'mplayer' with
the 'suiting' options for "kde" ?

Can't the gnome (meta)package depend on gmplayer which builds 'mplayer' with
the 'suiting' options for "gnome" ?

Can't the pure mplayer package build the minimal, functional requirements???

I'd very much like to see a "minimal" mplayer package.

> On a similar rationale, I'd argue that mplayer ought not to be linked
> against SDL.  After all the SDL output is generally not used (at least
> in my case, so I tune my build to exclude it).  

Fine, if mplayer "works" without SDL, then we should build the "pure"
mplayer without SDL.

> But there will
> certainly be binary-only users that want SDL support and we should not
> force them to rebuild anything in that case.

i) binary only users do not build ANYTHING. [argument = void.]
ii) the "gmplayer" and "kmplayer" packages offer enough hook to enable SDL
   where it is required for the appropriate "desktop environment".

Regards,

-Martin