[cc line trimmed]
In message <[EMAIL PROTECTED]>, Eugene Grosbein
<[EMAIL PROTECTED]> writes
I know. I will never 'rebuild all ports', I don't think that's Right Thing.
I've upgraded once from 4.11-STABLE to 6.0-RELEASE (binary upgrade
over existing system) and all ports worked nice, including X, brousers etc.
The only problem was a change of locale on-disk format that had simple
workaround.
I still have a.out binaries built under 2.2.8 running
under production 4.11-STABLE, they run just fine.
Modern operating system just have to offer binary backwards
compatibility for user-level, IMHO.
I have backups and when 'the same thing' happen again for a library
I forgot to move to lib/compat, I'll restore it there and continue
to use it.
It's your choice, but from a security perspective, this worries me.
You will have applications you are using linked against FreeBSD
libraries that no longer have any FreeBSD security team support.
misc/compat3x is marked as Forbidden / Ignore in the ports tree due to
an unfixed security bug that isn't going to be fixed (the effort isn't
felt to be worth it). I would expect misc/compat4x to land up that way
sooner or later as there's no longer any security team support for 4.x.
From a security point of view, this suggests that all 3.x and earlier
binaries should be rebuilt. I would be wanting to rebuild any binaries I
could that weren't built on relatively modern 5.x and upwards. By
relatively modern, I mean no more than one point release away from the
current one, and ideally no release that doesn't have current security
team support.
Security issues with ports are fixed by upgrading them - to a higher
PORTREVISION if not a later version. Some of the ports that have got
security related updates are fairly key libraries such as OpenSSL (I
tend to use ports OpenSSL on my machines as it's more up to date than
base system OpenSSL).
Indeed, whether you're using base OpenSSL or ports OpenSSL, how are you
going to rebuild libraries for binaries built on old releases? You could
fire up an old release to do so, maybe taking advantage of
virtualisation to do so, but that rapidly becomes a lot of work. As soon
as you need to upgrade one dependency based on an older release, you
have a potentially complex problem on your hands, especially as the
ports tree no longer supports 4.x or earlier.
Even running as you are now gives you some overhead. One slip and you're
reaching for a backup to restore libraries to fix whatever is broken.
portupgrade -af can be somewhat painful on systems with plenty of ports
installed. However, if you are not tracking -CURRENT and you don't
upgrade to a new major release at anything earlier than -RC stage (7.0
had an ABI change between -BETA3 and -BETA4), that should be needed just
once per major version.
By not rebuilding ports and other applications after a major version
upgrade, you throw away any advantages of building with new libraries
and toolchain components on the new releases if you continue to use old
binaries.
If you build ports with default options and knobs, you can use the
packages that are available, at least as a starting point. I use a fair
amount of customisation, so I compile the lot on my boxes. I keep the
number of installed ports down fairly aggressively, which helps.
Before too long:
7.x will be the mainstream release
6.x the legacy release for those who need more time before jumping to
7.x
and 8-CURRENT the bleeding edge.
5.5 is the last planned release from the 5.x line; it has an estimated
End of Life (from a security team point of view) of 31 May 2008. That
may slip by a bit depending on when 7.0-RELEASE ships, but I suspect the
entire 5.x branch will go EoL in mid 2008 and the ports tree will drop
5.x support shortly afterwards.
My main use for FreeBSD is as a server OS. My policy for the OS is to
track the current -RELEASE in my chosen major version fairly closely and
track the security fixes immediately. I'm currently on 6.2-RELEASE-p9 -
I'll evaluate 7.0-RELEASE after it is released, and intend to jump to
that rather than 6.3-RELEASE, even though the more conservative option
is 6.3-RELEASE.
I track the ports tree fairly closely, not least because I'm a ports
maintainer.
I am currently tracking RELENG_6_3 and RELENG_7 (I'll switch to
RELENG_7_0 when that's created) on non critical and virtual machines for
ports testing purposes. I won't use those machines in production as a
matter of policy - even though I'm considering new Dell Poweredge 2950
III hardware. My reading of the CVS logs suggests that the Mark III 2950
would require 6.3, 7.0 or backporting driver changes to 6.2 because
mfi(4) in 6.2 doesn't support the new PERC6/iR RAID controller on the
version III boards.
More than likely, I'll defer the hardware purchase until 7.0-RELEASE is
available. I know the mfi changes I'll need are in RELENG_7, and I'd
hope there's no problem with Harpertown processors (the new Penryn based
E54xx Xeons).
You may well have different priorities to mine in terms of what you
upgrade to and when - but I believe that you should consider the
security implications of your actions.
Best wishes,
David
--
David Wood
[EMAIL PROTECTED]
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
