libmad developer package

[markd at macports.org]

mark brethen <mbrethen at aim.com> on Saturday, May 19, 2007 at 7:05 AM -0800
wrote:
>Just to update you on the status. I contacted the mp3splt author at 
>sourceforge.net and he was able to walk me through the install. After 
>updating the libmad port I had to use
>
>export CFLAGS="$CFLAGS -I/opt/local/include"
>export LDFLAGS="$LDFLAGS -L/opt/local/lib"
>
>before configuring libmp3splt. The latest build of mp3splt (subversion) 
>fixes the cddb function. This doesn't work in the version that the 
>mp3splt port installs. If someone would guide me, I could create an 
>alternate (i.e. subversion) port install.

Ah I see. When installing software manually,  it will usually need to be
told where to find MacPorts libraries.  That is only one reason I don't do
it anyore.  If a port I need doesn't exist, I create it.

I don't understand the difference between libmp3splt and mp3splt.  Do we
need a port for each?

Also, there are several ways to handle updating a macport to handle newer
(but beta or alpha) code.

1) One way is to create a portname-devel package in cases where a new
version introduces incompatibilities *and* actual users we currently have
will want to use both.  Just the mere hypothetical possibility of needing
both is insufficent to create to ports, and only to be done when necessary.

2) If the alpha or beta is fairly stable, or the user base of the port is
low, or the bugs solved are significant enough that is is preferred to use
the beta over the release for most users, then it is justified to use
betas, release candiates, and even alpha code under the right
circumstances.  We don't like port and variant proliferation without good
reasons.

So the question is, is the mp3splt2.2_rc1 solve your problem?  And in your
judgement does it meet the criteria of #2?  If so, we could update the
port to rc_1.  If not, if the particular bugfix in subversion is a
discrete patch or patches, those could be added to the port to make the
port more usable.

Mark