On Fri, Jun 10, 2005 at 05:36:09PM +0200, Thomas Klausner wrote:
> This is getting silly.
> 
> On Fri, Jun 10, 2005 at 04:29:54PM +0100, Alistair Crooks wrote:
> > "Identical", where the sources differ? I think not.
> 
> This is the effective change to the sources:
> diff -u pkgsrc/pkgtools/pkg_install/files/add/perform.c:1.30 pkgsrc/pkgtools/pkg_install/files/add/p
> erform.c:1.31
> --- pkgsrc/pkgtools/pkg_install/files/add/perform.c:1.30        Sat May 28 02:50:46 2005
> +++ pkgsrc/pkgtools/pkg_install/files/add/perform.c     Fri Jun 10 01:37:21 2005
> @@ -67,6 +67,26 @@
>  static package_t Plist;
>  static char *Home;
>  
> +/*
> + * Some systems such as OpenBSD-3.6 do not provide PRIu64.
> + * Others such as AIX-4.3.2 have a broken PRIu64 which includes
> + * a leading "%".
> + */
> +#ifdef NEED_PRI_MACRO
> +#  ifdef PRIu64
> +#    undef PRIu64
> +#  endif
> +#  if SIZEOF_INT == 8
> +#    define PRIu64 "u"
> +#  elif SIZEOF_LONG == 8
> +#    define PRIu64 "lu"
> +#  elif SIZEOF_LONG_LONG == 8
> +#    define PRIu64 "llu"
> +#  else
> +#    error "unable to find a suitable PRIu64"
> +#  endif
> +#endif
> +
>  /* used in build information */
>  enum {
>         Good,
> 
> The rest is autoconf-related stuff.
> 
> I don't see any reason for a version number change for this.

You may not, but others have valid reasons, it seems to me.

The justification for not bumping the version number is weak, to say
the least, especially when viewed by the way that we used to calculate
the version number, which is beginning to look more and more appealing
to me as this debate goes on.

Once again - I do not understand your reluctance to bump the version
number except to encourage sloth and indolence on behalf of some
system administrators out there. If the tools need fixing, please fix
them, rather than dragging this out any further.

Thanks,
Alistair