On Sat, Apr 5, 2008 at 4:20 AM, Daniel Rahn <[EMAIL PROTECTED]> wrote: > On Saturday 05 April 2008 03:24:26 Keith Richie wrote: > > That's something I don't understand. Why there would be a want to > > retain backwards compatibility with an older version of glib that is > > from July 2007 (2.12.13) Granted Debian Stable uses this version, but > > there is also a .deb for pan 0.132. I don't see the correlation > > between an individual using a "Stable" distro with an older tool > > chain, and wondering why new svn releases aren't compatible? > > If the new svn release contains new features and is a candidat for a new > major release, well, break backwards compatibility and require newer > libs. That's not a problem and how the world mostly ticks. > > But right now svn only contains bugfixes. And that's the reason I > personally want to make them compile on the older distributions too.
I'll not disagree here. That is easily the best choice. > > Not everybody recompiles half of the distribution day after day. There > are people that just _use_ the machine and require a bugfix once in a > while. So if the distribution is still maintained, I don't see why a > bugfix in svn should break compatibility. > Duncan's the gentoo user ;) THIS would make Pan stand out. Can't count how many times I've attempted to compile a new upstream version of _foo_ only to be dismayed by unavailable dependency versions in the current point release. The solution was to wait for the next point release, or move to a rolling release distro. By contrast, here's what Ubuntu did. +pan (0.132-2ubuntu2) hardy; urgency=low + + * Fix FTBFS with moved glib header. + + -- Matthias Klose <[EMAIL PROTECTED]> Fri, 25 Jan 2008 10:25:44 +0000 and for gcc4.3 in October +pan (0.132-2) unstable; urgency=low + + * Updated patch to fix FTBFS with gcc 4.3 snapshots. (closes: #441575) + + -- Norbert Tretkowski <[EMAIL PROTECTED]> Wed, 03 Oct 2007 21:54:22 +0200 Are they not sharing their work? I haven't seen their comments in the Pan mailing lists. But I didn't look that hard either. Their g_assert patch is at the very end of the .diff file. > And after all, glib changed the API, not PAN. One project ignoring > unwritten rules (never change the API without changing the major > release) should not make other projects follow the same path. > > Just my 2 cents. > > -Daniel > > > > > _______________________________________________ > Pan-users mailing list > Pan-users@nongnu.org > http://lists.nongnu.org/mailman/listinfo/pan-users > I can see how fixing the code to compile on maintained distros should be the way to do it. If it isn't done that way, a choice to exclude those still running 2.12, which isn't _that_ old. Slackware 12 and Debian Etch use 2.12, Slackware 12.1RC upgraded to 2.14. Just two examples. Or have the maintainers apply patches. That can get ugly and messy. Who's to say if the patch is correct and not causing bugs. I've seen 3 different g_assert patches now. Good thing I'm not a programmer. I'd attempt to kludge it up in the configure file looking for glib version then define how to go from there. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
