Re: mplayer & qt?

["Julio M. Merino Vidal" <jmmv84%gmail.com@localhost>]

On 9/18/06, Martin S. Weber <Ephaeton%gmx.net@localhost> wrote:
> 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].

Then change the options you use.  That's what they are for.

You are not building the binary packages that will end up in ftp.n.o
(the ones that are then used by those people that do not want to build
stuff on their own), so you can change whatever build-time options you
want.

> (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" ?

Why?  I'm a GNOME user but in no way I want gmplayer.  I am happy with
mplayer, but I want it with esd support.

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

And what are the "minimal" requirements?  That is very subjective.

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

But somebody has to provide them with those binary packages.  And that
is us.  And that happens with the DEFAULT OPTIONS.  And this is why
the DEFAULT PACKAGES need to be as useful as possible.

--
Julio M. Merino Vidal <jmmv84%gmail.com@localhost>
The Julipedia - http://julipedia.blogspot.com/