library versions

[Ryan Stonecipher-Fisher]

On Wed, May 19, 2010 at 03:40,
<macports-dev-request at lists.macosforge.org> wrote:
[snip]
> ---------- Forwarded message ----------
> From: Ryan Schmidt <ryandesign at macports.org>
> To: Takeshi Enomoto <takeshi at macports.org>
> Date: Wed, 19 May 2010 03:40:08 -0500
> Subject: Re: library versions
>
> On May 19, 2010, at 03:32, Takeshi Enomoto wrote:
>
>> I recently updated hdf4. During the update process I found that hdf4
>> is incompatible with jpeg 7 and higher.
>> I decided to compile libjpeg.a in pre-configure and keep it and
>> headers in ${prefix}/lib/hdf4.
>
>> MacPorts seems to adopt the philosophy  ``the newer the better''.
>> Sometimes the new one might have a bug or incompatible changes.
>
>
> Hopefully, more often, it's the old version that has the bugs, that the new version corrects, but anything's possible.
>
> We have the existing habit of creating ports with version numbers in the name, if older versions are still required by some ports. For example, since hdf4 requires jpeg 6, we could create a new port jpeg6 (svn copy'd from the last version of the jpeg that had version 6) to provide that version of the library and headers.
>

Could the same style be applied to resurrect the mpeg4ip version of
libmp4v2 (the version abandoned by its maintainers and forked into the
current google code mp4v2 project) to fix gtkpod?
The release version of gtkpod still depends upon the old library, and
its current development trunk is not marked as "release candidate" or
anything else that would suggest it is stable enough to be unleashed
on users.
What should be done if the two libraries have headers or binaries with
identical filenames?

Ryan Stonecipher-Fisher