On Wed, May 19, 2010 at 03:40, <[email protected]> wrote: [snip] > ---------- Forwarded message ---------- > From: Ryan Schmidt <[email protected]> > To: Takeshi Enomoto <[email protected]> > 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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
