Subject: pkg/21703: suboptimal distfile for audio/openal
To: None <gnats-bugs@gnats.netbsd.org>
From: None <jschauma@cs.stevens-tech.edu>
List: netbsd-bugs
Date: 05/28/2003 11:32:43
>Number:         21703
>Category:       pkg
>Synopsis:       suboptimal distfile for audio/openal makes it difficult to use package across different platforms
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed May 28 15:33:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Jan Schaumann
>Release:        NetBSD 1.6.1_STABLE
>Organization:
	
>Environment:
	
	
System: NetBSD dogfish-head.cs.stevens-tech.edu 1.6.1_STABLE NetBSD 1.6.1_STABLE (BOCK) #2: Thu May 22 15:59:50 EDT 2003 jschauma@amstel.cs.stevens-tech.edu:/usr/stable-src/sys/arch/i386/compile/BOCK i386
Architecture: i386
Machine: i386
>Description:
	audio/openal attempts to provide a package for OpenAl (http://www.openal.org)
	Unfortunately, that website does not provide source-tarballs, but only
	anonymous cvs access.  As a result, we download the distfile from some
	other website, the name indicating that it's been fuzzed with to work
	under FreeBSD.

	Under Linux, this package doesn't build (haven't looked much closer at
	this yet, some pthread issue), but I suspect that if we used the original
	sources, we would have better chances at compiling it on different
	platforms.

	Also, this approach makes it more difficult to update the package,
	as the distfile is not in synch with the actual sources (how could it,
	if they are only available via cvs).
>How-To-Repeat:
	Inspect http://www.openal.org/downloads/ and /usr/pkgsrc/audio/openal/Makefile

>Fix:
	I'm not sure if there are other packages, but we might want to consider
	determining an approach for building packages from anoncvs source
	distributions (ie 'make fetch' logs in and grabs the files, puts them
	into WRKDIR and sets the package-name to BASENAME-DATE).  This would
	also require a dynamic PLIST, and probably would be very cumbersome.
	Just a thought.

	Otherwise, the maintainer of the package might want to consider checking
	out the sources regularly and providing source-tarballs for use with
	this package.
>Release-Note:
>Audit-Trail:
>Unformatted: