The short answer is: it’s best if you use both testing and unstable.

Let’s consider the alternative: using only one catalog on all machines. If you use unstable (also in production), you’ll keep getting a lot of updates, and chances are that some of them will be broken. On the other hand, if you use only the testing catalog, there will be less churn, but you won’t spot problems in packages while they’re in unstable and you will increase chances of a bad package push to testing.

If you run a site where you have production and development / testing machines, you can use the unstable catalog for the ones that have higher instability tolerance. If anything breaks in unstable, you’ll notice the problem but it won’t be an operational issue for you. If you get back to us with a report, we’ll fix the it, and the bug won’t make it into the testing catalog.

The full announcement is in the CSW Users list archive.  The announcement includes details on how to continue using pkg-get if required.

We apologize if this causes you any inconvenience.

(the original announcement is on the users mailing list)

“unstable” is still the place for the most recent packages, that’s where we intially upload packages. “current” on the other hand now offers a middle ground. It points to “testing“, a branch which receives staggered package updates from “unstable”. Finally, “stable” is officially deprecated – which it de-facto was for quite some time now. You can still use it, but it is very old and won’t see updates. As a replacement for “stable” we’ve started to work on something called named releases. More on that in due time.

To sum it up in a picture

What’s next?

There’s still a bunch to do. Automating the “unstable” -> “testing” workflow, propagating the substantial backlog of updates from “unstable”, and getting a named release out of the door are among the main ones. In the meantime, the “Release Branches” page has been updated and the branches “unstable” and “testing” are your friends. Any questions? Let us know.

The result of this is that we’re going to steer our internal release processes toward as much automation as possible.  Although there are many details to sort out yet, we think that the new process will result in a much nicer work flow without sacrificing package quality.

• pkgutil: new option –cleanup. When invoked, scans for /var/sadm/pkg/*/install/obsolete. If it finds /var/sadm/pkg/CSWlibfoo/install/obsolete and nothing installed depends on CSWlibfoo, then CSWlibfoo gets removed from the system
• Support key package (/etc/opt/csw/pki, /var/opt/csw/pki). Change default homedir (Ben Walton)
• Parse option for download, incl. catalog and md5 (Maciej Blizinski)
• Include distribution (e.g. unstable) with pkgliststyle 2
• Support absolute paths in –output (Dago)
• Show last two parts of mirror path as distribution (e.g. dublin/core)
• Change default pkgliststyle to 2
• Speed up option -l with glob
• Silence “Checking integrity …” when –parse is on (4693@OpenCSW)
• pkgutil: eval ‘PATH=/opt/csw/bin:$PATH exec perl -x -w $0 ${1+”$@”}’ (PCA)
• pkgutil: fix pkgask/response bug (3205333@SF) (Julian Clifton-Thompson)
• pkgutil: fix a bug in –cleanup when using –yes or auto (admin not set)
• Do not duplicate mirrors present in pkgutil.conf in both /opt and /etc (4693@OpenCSW)
• Fix bug in hook support (Ben Walton)
• bldcat: add -q/–quiet option
• bldcat: improve support for non-CSW packages (3300709@SF) (Mark Heily)
• chkcat: add -c/–nocyclic option to skip cyclic dependency checking, helps speed a lot
• chkcat: suppress warning exit code 1 when using –erroronly
• chkcat: multiple catalog files can be specified and checked as a set (Maciej Blizinski)