[packman] Why do we build libcaca ?

[Pascal Bleser]

On 2011-02-25 22:17:47 (+0100), Manfred Tremmel <manfred at links2linux.de> wrote:
> Am Freitag, 25. Februar 2011 schrieb Pascal Bleser:
[...]
> > * have to upgrade libcaca when they install our xine, MPlayer,
> >   ... packages when there is no real need for it (our packages
> >   all build just fine agains the libcaca versions that are
> >   shipped by the distros -- except for 11.1)
> 
> I think most peoply simply press the ok button to fullfill the 
> dependencies and don't think about what happens. But I have no problem 
> to build libcaca only for the oldies.

Yes, there seems to be a surprisingly large amount of people who
always use "zypper dup" to install updates, in which case the
"vendor lock protection" doesn't apply and, hence, those would
get the newer versions from Packman.

[...]
> > I mean, if there is really a good reason for us to force an
> > upgrade of a dependency (e.g. better performance, bugfixes, ...)
> > then, of course, it's a totally different story and I agree that
> > we should provide the newer version.
> > But I don't think it's the case here.
> 
> I think 99% of the users will never use a videoplayer with caca-
> textoutput on console. For myselve I've done it a view times for 
> testing, but for nothing else. It's not realy usefull. So it's 
> completely unimportend even if we would build the mediaplayers on 
> opneSUSE 11.1 and SLES without caca.

Hmmmmmmm... that's very true actually...
So, would you be fine if I disable building libcaca for 11.1 and
SLE_11 as well ? (and build MPlayer, vlc, ... without libcaca
support on those)

cheers
-- 
  -o) Pascal Bleser <pascal.bleser at opensuse.org>
  /\\ http://opensuse.org -- I took the green pill
 _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.links2linux.de/pipermail/packman/attachments/20110225/135fffcc/attachment.sig>