>Number:         29912
>Category:       pkg
>Synopsis:       xine should not depend on restricted Win32 codecs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 07 07:23:00 +0000 2005
>Originator:     reed@reedmedia.net
>Release:        NetBSD 1.6.2_STABLE
>Organization:
http://bsd.reedmedia.net/
>Environment:
	
	
System: NetBSD rainier.reedmedia.net 1.6.2_STABLE NetBSD 1.6.2_STABLE (MYKERNEL) #1: Tue Jun 1 12:16:43 PDT 2004 reed@rainier.reedmedia.net:/usr/src/sys/arch/i386/compile/MYKERNEL i386
Architecture: i386
Machine: i386
>Description:
A NetBSD end-user wrote:

> I've tried to install kde-3.3.2 per ftp from
> /pub/NetBSD/packages/2.0/i386/All/ and end up with an incomplete
> installation - the kdemultimedia-3.3.2nb2.tgz package fails because one
> or more of the xine packages fail, because win32-codecs-??? fails.

The following is from my old emails:

 packages with NO_BIN_ON_* restricted dependencies (like xine-lib
 http://mail-index.netbsd.org/tech-pkg/2004/05/10/0008.html

 add a xine-lib definition for XINE_USE_WIN32_CODECS ?
 http://mail-index.netbsd.org/tech-pkg/2004/05/28/0011.html

I see that xine-lib depends on win32-codecs (on my platform).

But win32-codecs has NO_BIN_ON_CDROM and NO_BIN_ON_FTP defined.

It seems like we should not have any packages depend on something by
default that has restricted NO_BIN_ON_* or NO_SRC_ON_* defined.

I don't want to accidently upload my new packages to a
publically-available server.

Is it okay if I add the following?

XINE_USE_WIN32_CODECS?= NO
# Used by xine-lib to choose to depend on win32-codecs
# which have an unknown license.
# Possible: YES, or NO.
# Default: NO

Then by default it won't have:

PLIST.common:${I386}lib/xine/plugins/1.0.0/xineplug_decode_qt.a
PLIST.common:${I386}lib/xine/plugins/1.0.0/xineplug_decode_qt.so
PLIST.common:${I386}lib/xine/plugins/1.0.0/xineplug_decode_w32dll.a
PLIST.common:${I386}lib/xine/plugins/1.0.0/xineplug_decode_w32dll.so
(This is the list I made from last May 2004.)

And more importantly we will be able to have xine packages available by
default.

Maybe someone else can make a xine-win32-plugins package for just those.

>How-To-Repeat:
Use binary packages to install something that depends on xine and have it fail due to missing win32_codecs (because it was never uploaded).
>Fix:
Maybe it could be a BUILD_DEPENDS for win32_codecs.
I don't know if that will cause the xine-lib to be an issue itself.

Or maybe build it without any win32_codecs support. But then how could
it be added later?

As for myself, I like to use win32_codecs. I have needed it a few times.

Also see:

  packages to install restricted files instead of NO_BIN_ON_*
  http://mail-index.netbsd.org/tech-pkg/2004/05/12/0011.html
  http://mail-index.netbsd.org/tech-pkg/2004/05/12/0013.html

>Unformatted: