View Single Post
  #3   (View Single Post)  
Old 16th February 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default Planning for first time -current use

In another thread...
Quote:
Originally Posted by daemonfowl View Post
...I'd appreciate it much if you could start a thread on what a current-box user should take care for at a regular basis .. things to check .. links to keep up with ...
The following is just opinion.

Advantages to deploying -current:
  • Early adoption of new features and functionality when they are deployed
  • Testing of new features and functionality, in cooperation with the Project, before they are deployed or fully functional, and influencing their quality and scope
  • Active participation in break/fix resolution -- your own reported bugs, or bugs reported by others.
  • Testing new and updated ports before they are deployed, in cooperation with the ports' maintainers.
  • Deploying new and updated ports
  • Deploying all bug fixes; in comparison relatively few fixes are backported to -stable.
Disadvantages to deploying -current:
  • As -release features/functions are heavily tested in comparison to developmental code before commit, -release/-stable mitigates risk of errors introduced with new functionality.
  • More admin skill is required -- synchronization of ports / packages is left to the admin to deal with.
Getting to -current has only one supported path -- binary install or upgrade: Install the most recent snapshot, or upgrade to the most recent snapshot. Source code builds to implement -current from -release/-stable are not supported.

There are two methods to staying -current: a) upgrade to a more recent snapshot, or b) Build from -current source code.
While b) may appear to be at odds with the insistence on a binary installation/upgrade for initially reaching -current, keep in mind that a supported -release will always be at least two or three months behind -current, due to the development and deployment cycle. The number of architectural changes that may occur between -release completion and when it is available for installation make building -current from source on a -release platform sufficiently complex to be unsupportable by the Project.

If one builds from source with a relatively frequent cadence, the manual steps required to implement architectural changes are significantly simpler.
Required knowledge/skill:
  • Building packages from ports
  • Diagnosing port building problems caused by sync errors -- this can be obtained through experience. While learning, the impact is not being able to update the affected package(s) or install the affected new package.
  • Using cvs(1) -- for the ports tree, at minimum.
Required documentation:
  • The Following -current FAQ. This regularly updated document lists structural changes the admin needs to be aware of since the last -release, and, what manual action must be taken. In some instances, a listed change may require significant admin skill. In others, the change may be automated by the use of sysmerge(8).
The use of -current will take, at minimum, upgrading to the most recent snapshot and running sysmerge.

So called "snapshot packages" for the popular architectures are built from time to time, and are available from your nearby mirror. But they will not be exactly in sync with the snapshot, and sometimes, install or update of some packages will fail. If you wish to install or update those packages, you will have to build them yourself, using a ports tree in sync with your OS. If you update from a snapshot, you may find the "-D date_spec" option for the cvs checkout command helpful to keep the ports tree in sync with your snapshot ... depending on the date the snapshot was built and the date of a -current tree.
Reply With Quote