pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
pkg/29912: xine should not depend on restricted Win32 codecs
>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@localhost
>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@localhost:/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:
Home |
Main Index |
Thread Index |
Old Index