First I want to apologize. This should have happened a bit sooner in
our release cycle than now. To be honest I had slipped into "We have
symbol versioning for our libraries now" mode. But only a few of the
libraries currently have that turned on and I sorta forgot we still need
to deal with all the shared libraries that do not have symbol versioning
enabled yet. Sorry for the hassle this will cause.
Today with svn commit 195767 I bumped the version number of all
non-symbol-version-ed shared libraries in preparation for 8.0-REL. We
do this just in case API/ABI changes occured in head between 7.0 and
now, it lets us provide the older library versions as "compatibility
library ports" in the ports tree.
The problem is that as of the next time you update a machine that had
been running -current you are best off reinstalling all ports or other
applications you have on the machine. When you reboot after doing the
update to the base system everything you have installed will still work
because the old shared library versions will still be there. However
anything you build on the machine after its base system gets updated
would be linked against the newer base system shared libraries but any
libraries that are part of ports or other applications (e.g. the Xorg
libraries) would have been linked against the older library versions.
You really don't want to leave things that way.
The ports folks will be starting up a fresh package build now but it
takes some time for full package runs like this to complete, get
uploaded, and then propagate out to the mirrors. If you tend to use
pre-built packages instead of building them as ports yourself you might
want to just hold off on updating anything until they let us know a
fresh set of packages is available. And BETA3 will definitely be
scheduled for after the fresh set of packages becomes available.
And again - sorry for the hassle.
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090719/bfa02e69/attachment.pgp
On Sun, 2009-07-19 at 20:26 +0200, Thomas Backman wrote:> On Jul 19, 2009, at 20:16, Ken Smith wrote: > > The problem is that as of the next time you update a machine that had > > been running -current you are best off reinstalling all ports or other > > applications you have on the machine. When you reboot after doing the > > update to the base system everything you have installed will still > > work > > because the old shared library versions will still be there. However > > anything you build on the machine after its base system gets updated > > would be linked against the newer base system shared libraries but any > > libraries that are part of ports or other applications (e.g. the Xorg > > libraries) would have been linked against the older library versions. > > You really don't want to leave things that way. > So, to be clear: a fresh ports tree and "portupgrade -af" after > building and installing r195767+ should be enough to solve any > problems? (installkernel, installworld, reboot, portupgrade -af) >Correct for those of you who let portupgrade do all the building for you (which the example command you give does). The reason I'm being careful is portupgrade can also be told to fetch pre-built packages. At the moment that will not work, if you use that approach please hold off until the ports folks let us know the packages have been rebuilt. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090719/dd7b3c33/attachment.pgp
On Jul 19, 2009, at 20:16, Ken Smith wrote:> The problem is that as of the next time you update a machine that had > been running -current you are best off reinstalling all ports or other > applications you have on the machine. When you reboot after doing the > update to the base system everything you have installed will still > work > because the old shared library versions will still be there. However > anything you build on the machine after its base system gets updated > would be linked against the newer base system shared libraries but any > libraries that are part of ports or other applications (e.g. the Xorg > libraries) would have been linked against the older library versions. > You really don't want to leave things that way.So, to be clear: a fresh ports tree and "portupgrade -af" after building and installing r195767+ should be enough to solve any problems? (installkernel, installworld, reboot, portupgrade -af) Regards, Thomas
Ken Smith <kensmith@cse.Buffalo.EDU> writes:> First I want to apologize. This should have happened a bit sooner in > our release cycle than now. To be honest I had slipped into "We have > symbol versioning for our libraries now" mode. But only a few of the > libraries currently have that turned on and I sorta forgot we still need > to deal with all the shared libraries that do not have symbol versioning > enabled yet. Sorry for the hassle this will cause. > > Today with svn commit 195767 I bumped the version number of all > non-symbol-version-ed shared libraries in preparation for 8.0-REL. We > do this just in case API/ABI changes occured in head between 7.0 and > now, it lets us provide the older library versions as "compatibility > library ports" in the ports tree. > > The problem is that as of the next time you update a machine that had > been running -current you are best off reinstalling all ports or other > applications you have on the machine. When you reboot after doing the > update to the base system everything you have installed will still work > because the old shared library versions will still be there. However > anything you build on the machine after its base system gets updated > would be linked against the newer base system shared libraries but any > libraries that are part of ports or other applications (e.g. the Xorg > libraries) would have been linked against the older library versions. > You really don't want to leave things that way. > > The ports folks will be starting up a fresh package build now but it > takes some time for full package runs like this to complete, get > uploaded, and then propagate out to the mirrors. If you tend to use > pre-built packages instead of building them as ports yourself you might > want to just hold off on updating anything until they let us know a > fresh set of packages is available. And BETA3 will definitely be > scheduled for after the fresh set of packages becomes available. > > And again - sorry for the hassle.In my case, there is no upgrade with servers -- i have two servers (4.11-STABLE, 6.3-RELEASE). So plz don't worry. Only what i do upgrade is client which is my main desktop -- currently it runs as 7.2-RELEASE. Though! Don't worry because always i do upgrade as follow: => csup => make world => reboot => (after coffee time) => pkg_delete -af => pkg_add -r -v gnome (with several package) That's very fine and fast for me, anyway... -- Byung-Hee HWANG, KNU ? WWW: http://izb.knu.ac.kr/~bh/ "Come on, stick it in. Stick it in, Johnny, that's what you really want." -- Margot Ashton, "Chapter 1", page 12
Quoting Ken Smith <kensmith@cse.Buffalo.EDU>:> First I want to apologize. This should have happened a bit sooner in > our release cycle than now. To be honest I had slipped into "We have > symbol versioning for our libraries now" mode. But only a few of the > libraries currently have that turned on and I sorta forgot we still need > to deal with all the shared libraries that do not have symbol versioning > enabled yet. Sorry for the hassle this will cause....snip... Wouldn't this be a great opportunity to fix kern/133926 by bumping up the max username length? -- Chris Dillon - NetEng/SysAdm Reeds Spring R-IV School District Technology Department 175 Elementary Rd. Reeds Spring, MO 65737 Voice: 417-272-8266 Fax: 417-272-0015