[Flac-dev] in progress: Installer Package for Mac OS X (for 1.1.1 binaries)

Josh Coalson xflac at yahoo.com
Wed Jan 26 11:35:41 PST 2005

--- Brian Willoughby <brianw at sounds.wa.com> wrote:
> Hello,
> I noticed that there is no convenient installer package for Mac OS X.
>  The  
> various GUI programs that use FLAC seem to only have flac 1.1.0, so
> there is no  
> simple way for a non-developer to install flac 1.1.1, other than
> manually  
> placing the various files where they belong.
> So, I have created FLAC-1.1.1.pkg.tar.gz, but I would like your help
> in making  
> it more complete.

this is great, I think this is something that would be useful
to have ongoing.  if you're willing to sign up as the maintainer,
I can host them on sourceforge as part of the regular release

> This package includes the pertinent files from
> flac-1.1.1-osx-ppc.tar.gz,
> but without the AUTHORS and other attribution files.  I don't know
> where to  
> install the attribution files, so I think it would be best to include
> that  
> information in the Installer UI itself.  If anyone would like to
> suggest the  
> appropriate text (possibly a subset of the AUTHORS file, or even the
> whole  
> file), then I will create another package with proper attributions in
> it.

I would say /usr/share/doc/flac-1.1.1/AUTHORS.  same with the

> Other issues:
> 1) It's obvious that flac and metaflac belong in /usr/local/bin/ and
> flac.1  
> and metaflac.1 belong in /usr/local/man/man1/, however I am a little
> worried  
> about placing the /html/ directory in /usr/local/share/doc/html/
> because it  
> seems like it might conflict with other Unix tools installed there. 
> When  
> manually installing flac 1.1.0, I just created a subdirectory named  
> /usr/local/share/doc/html/flac-1.1.0/ and moved the flac files there.
>  Any Unix  
> folks out there know what the standard should be for placing files in
> /usr/local/share/doc/html/ such that they do not conflict?

I think it should go in /usr/share/doc/flac-1.1.1/html

> 2) Because flac-1.1.1-osx-ppc.tar.gz has static linked binaries only,
> decided to do the same in FLAC-1.1.1.pkg.tar.gz, however there is
> some benefit  
> to having a more extensive Installer package for Mac OS X which
> includes the  
> FLAC and FLAC++ libraries.  That Installer package could easily
> install the  
> dynamically linked binaries since the libraries will be installed at
> the same  
> time.

I don't think it's necessary to have a development version with
libraries/headers/etc.  probably most people who need that already
have some setup like fink or just compile the sources.

in the basic tools pkg, having statically linked binaries really
cuts down on the user headache.  I don't see much need to have a
flac that can dyload a newer libFLAC since they are released

> I know how to build all of this, but I am asking for feedback on
> whether such  
> a package would be useful.  I've been distributing free programs for
> Mac OS X  
> which use the FLAC library, and I've had to instuct my users on how
> to manually  
> install the FLAC library.  I have incentive to put together a more
> extensive  
> package to make distribution of my software a little easier (I'll
> just tell  
> users to install the FLAC package before my app).

ah, I see, you're distributing without libFLAC?  I would suggest
to statically link also to cut down on the user headache.  I don't
really understand why an app maintainer would want to dynamically
link libs in most cases.  for libc and big/important stuff I can
see it, for apps using libs that may need frequent security
updates, yes, but for something like an audio app, why not just
static link?  FLAC releases are not that often :)


Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.

More information about the Flac-dev mailing list