Re: [Pan-users] Re: Anyone get pan compiling with gcc 4.3 yet?

[Keith Richie]

On Sat, Apr 5, 2008 at 4:20 AM, Daniel Rahn <address@hidden> 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 <address@hidden>  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 <address@hidden>  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
>  address@hidden
>  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.