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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"