Quarterly releases for ports/packages

K

kpa

This is very interesting, I wouldn't have guessed that we would get a "stable" ports tree/packages so soon.

http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-April/000079.html

January 2014 saw the release of the first quaterly branch, intended at
providing a stable and high-quality ports tree. Those stable branches are a
snapshot of the head ports tree taken every 3 months and currently supported
for three months, during which they receive security fixes as well as build and
runtime fixes.
Click to expand...

I really hope this turns out to be a working system. One of the biggest aggravations with the ports tree at the moment is that any single commit that is made with good intentions but has a problem can break large parts of the ports tree and the bad change is pushed to everyone who happens to be updating their ports tree at that time.

The URL for the branched (Q2) ports tree is https://svn0.eu.freebsd.org/ports/branches/2014Q2 (in Europe, replace with US mirrors if better for you).
 
Thanks for the reminder. Do you know if these trees can be integrated into the portsnap(8) -> ports-mgmt/portmaster work flow? As the former is part of the base install, shouldn’t we expect it to be possible? If I understand well, to use these stable branches we could use svnlite* as an alternative to portsnap.

* Curiously there’s no man page for it.
 
I don't think portsnap(8) can be used to fetch ports tree of the quarterly branch yet, it is written with the assumption that there is only branch in the ports tree, head. You'll have to use the packages or use svn/svnlite to fetch the quarterly branch of the ports tree.
 
Hi, is there any documentation where I can get more information on how quarterly works?

I hear that the quarterly branch is updated every three months, yet when I look at the timestamps, there appear to be constant updates right up to today. Are those only for security updates? Or will major versions of software be updated as well? I see quarterly has Firefox 28, and latest has Firefox 29. If I use 2014Q2, I'd like to be sure my system won't be updated to FF29 and its godawful Australis UI. I know about pkg lock, I'm more concerned about having a reproducible system after reinstalls, and it doesn't appear that 2014Q2 is being offered as a download in ISO form (although that would be wonderful if it were.)

How will the 2014Q3 update happen? Will it just be an overnight copy of then-latest over to quarterly, such that the next invocation of pkg pulls the new digests and we're stuck on it?
 
No documentation yet because this all seems to be very experimental and there hasn't been too much noise about it so that people don't get their hopes too high up. I've gathered that the updates to the quarterly branches will be only security patches and critical fixes to bugs that prevent building of some ports, no new versions.

The next quarterly branch Q3 of the ports tree will be copied from the head branch and a new set of packages will be made from the Q3 branch to the quarterly package repository. Support for the previous quarterly branch and the packages will end at that moment.
 
The simplest way to switch to the quarterly packages is to edit /etc/pkg/FreeBSD.conf (if you're on FreeBSD 10) or /usr/local/etc/pkg/repos/FreeBSD.conf (if you're on earlier version than 10 and you created the repository configuration yourself) to read:

Code: 
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
 
I see, thanks. I am not sure what I want to do now.

Option 1. stick with release, build PHP with Apache support, stick to Firefox 26.
Option 2. go with quarterly, lock Firefox 28, deal with periodic fallout from upgrades, install FF28 package manually on reinstalls after Q3 push.
Option 3. go with latest, run Firefox-ESR 24 until Firefox 31 bumps the ESR version, and then lock it. From there, try my best to keep manually installing FF28 on future installs.

FF in this case being symbolic for any packages that end up proving problematic. The goal being to give me buffer time until a) the problems are fixed, or b) an alternative program is found.

I would definitely feel more at ease with option 2 if there were a bit more commitment to the idea. That feels the closest to my favorite model, used by Debian.
 
You must log in or register to reply here.
Back
Top