Subject: Massive PKGREVISION bump coming this Fri-Sat
To: None <tech-pkg@netbsd.org>
From: Todd Vierling <tv@duh.org>
List: tech-pkg
Date: 09/26/2004 23:51:18
SWEEPING PKGSRC VERSION BUMP COMING!

This change is scheduled for Saturday, October 3, at 00:00 UTC (which means
that it's actually on Friday evening for the folks on the west side of the
Atlantic Ocean).

_______________________________________________
SUMMARY (read on for important technical notes)

In order to address one bug report and many comments about the problems with
pkgsrc's use of libtool, there will be a rework of devel/libtool[-base] this
week to switch to its default (on most platforms, "linux-elf") style of
library versioning in libtool.

This will mean that minor ABI updates will not force a major shlib version
bump on some platforms, and that devel/libtool-base will follow the
out-of-the-box version naming rules for shlibs on each OS.

_______________
TECHNICAL NOTES

First, a NOTE to people on Irix:  After this change, the version of ld(1)
you use -- GNU ld or SGI's ld -- determines the naming of shlib suffixes.
This is the way libtool works out of the box, and unless specifically
requested by the Irix pkgsrc maintainer(s), will be the way pkgsrc libtool
works as well.

Now, for all pkgsrc users:

As part of this change, there will be a blanket PKGREVISION bump to all
packages using USE_LIBTOOL, and all BUILDLINK_RECOMMENDED versions will be
updated to match.  If you are building packages from source with pkgsrc
defaults, you will be faced with updating dependency libraries due to the
RECOMMENDED bumping.

If you wish to defer the forced upgrade to the new libtool versioning, you
may set the following in mk.conf to let "new" packages continue to link
against "old" libtool-based libraries.  This is not ideal, but may provide a
smoother transition path for more critical machines.

    IGNORE_RECOMMENDED=YES

When this is set, make sure not to build binary packages for redistribution,
as they will have the wrong shlib names/versions of dependencies encoded in
them.  Likewise, don't expect "make replace" to upgrade an "old" libtool
library to a "new" package; the dependents will still need to be recompiled.

______________
STATUS UPDATES

Additional information on the status of this change will be posted no later
than Thursday, September 30, at 00:00 UTC.

____________________
TO PKGSRC DEVELOPERS

Please feel free to continue updating/changing packages as normal.  I'll be
watching pkgsrc commits and updating my working tree as needed in the
interim.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>