freebsd stable - Jun 2008 - CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3

On Wed, Jun 11 2008, Robert Watson wrote:

On Wed, 11 Jun 2008, Paul Schmehl wrote:
>> From a security standport, backporting fixes to previous versions of
ports
>> creates a difficulty.  It's much harder to tell, for example, if a
RedHat
>> "port" is vulnerable or not, because RedHat uses their own
proprietary
>> versioning system to define "where" a particular
"port" is at.
>>
>> So, while your system might *say* it's running php version 5.2,
it's really
>> *not* vulnerable because in RedHatese it's version
5.2.1.6.92000.p-2.1 (I'm
>> just making that up.)
>>
>> If this idea ever gets off the ground, I *hope* the folks involved with
find
>> a rational, logical way to define the versioning so that it's not
>> hieroglyphics to the average person.
Egyptian hieroglyphics was a very noble system the secret of which was,
in the days of old, in the possession only of the Hierogrammatists, or
initiated
Egyptian priests. Many occult alphabets and ciphers derived its origin from
egyptian sacred ciphers, as also everything we know as cryptography today.
I guess our english alphabet would be equally strange and uknown to them.
But reading widely available documentation on Redhat's versioning system
would definetly help in understanding its details.

Everything after second - (dash) like in ftp-0.17-33 is Redhat's release
version. In this case this is thirty third release or patch. It is similar to
FreeBSD's naming convention.
You can check changelog and see what has changed since release 1
by issuing:
$ rpm -q --changelog <package>

So the system is very clear and precise, just like FreeBSD system.
The only difference is that upstream version of the package changes
a lot more often than on redhat/centos.
> We already do this for some
>ports, in that the people involved in adapting and maintaining some of the
>larger/more critical parts, such as X.org, KDE, Gnome, and quite a few
others,
>spend vast amounts of time ensuring that things work well, but largely
without
>the help of revision control in the ports tree.  I'm not proposing we
>incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we
>could better present the choices reflected there.  That doesn't help
users of
>random tiny software packages, and I'm not sure anything can, but
perhaps we
>can provide a smoother incremental maintenance path for some key packages.
I think that most system administrators who maintain many FreeBSD servers in
data center environments do not really care about "X.org, KDE, Gnome"
and
other desktop applications having those -SECURITY patches backported.
The real concern here is about common server applications. I think that
cutting edge users who run FreeBSD on their workstations are perfectly
aware that things can sometimes break, and to a degree they accept that
risk. But system administrators running mission critical nonstop systems 24/7
cannot accept such risk with the server ports they are using. So if anything
can be improved in ease of upgrading, backporting etc. this is the main
area to investigate, so as to make FreeBSD the most stable and reliable
Unix operating system out there.

-- 
Andy Kosela
ora et labora