CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3

[Robert Watson]

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.

I hope not to offend the ports folks in saying this, but it seems clear to me 
that the narrower scope and better-defined components of the base system have 
(over time) lead to a much easier incremental upgrade path than ports and 
packages.

It's not clear to me how you could apply the same level of attention to 
something as large as the ports collection, except perhaps to select a subset 
of ports you care "more" about, and provide a higher quality of service for 
them.  In effect, try to find a semantically richer middle ground between 
"it's someone else's problem, our role is primarily to bundle" and "it's 
entirely our problem and in revision control".  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.

Mind you, ports really isn't my area, so I am at significant risk speculating 
in this area.  Experience with the base system shows that the real work is 
always in the details, and hardly ever in the big ideas, and so only by truly 
implementing a system and trying it out can you determine whether it really 
works in practice.  It's easy to wave ones hands at a high level (as I've 
done), but it's the proof-of-concept that matters.

Robert N M Watson
Computer Laboratory
University of Cambridge