* On 2014-04-28 at 11:43 BST, Nicholas Lee wrote: > On Mon, Apr 28, 2014 at 9:19 PM, Jonathan Perkin > <[email protected]> wrote: > > > * On 2014-04-27 at 23:43 BST, Nicholas Lee wrote: > > > > > Is there a location where individual package changelog files are > > > kept for pkgin full-upgrade/upgrade? > > > > We include a list of changes in the commit logs for each package, but > > there is no easy way to pull those out and correlate them with the > > binary package. > > > > There is currently no place to store such information in a binary > > package, but it would be a reasonably nice project to work on if > > someone wanted to start hacking on it, and I can see that it would be > > quite useful. > > Can you push this commit logs per packaging like with Freebsd: > http://svnweb.freebsd.org/ports/head/mail/dovecot2/?view=log. That system > is almost sufficient.
Sure, it's all available, see e.g. https://github.com/joyent/pkgsrc/commits/trunk/mail/dovecot2 > > > How long is each set (2013Q4, 2014Q1, etc) of packages maintained? > > > > Officially only the most recent branch is maintained, so 2014Q1 is the > > current supported branch, and anything older is obsolete. Maintenance > > means that the pkgsrc releng team (community volunteers) backport > > security and important fixes from pkgsrc trunk to the maintenance > > branch. > > > > However, we (Joyent) continue to maintain older branches in a best > > effort capability, and will e.g. backport fixes such as Heartbleed to > > as many branches as we deem necessary. > > > > At present we do not have a well defined EOL policy, but this is > > something that will need to be addressed as the number of branches > > grows. > > Is there policy for when datasets become active? I notice that 2014Q1 is > not in the standard repository: As soon as possible after the branch is released. It's still taking longer than we would like to do this, but we're improving the process each time. The 14.1.0 images will be released shortly. > Further, is there much difference between minor versions - eg 13.4.0 and > 13.4.{1,2}? Or is that simply a simple pkgin upgrade? Minor releases are for fixes to the image or upgrades for important packages, e.g. OpenSSL. We don't ship minor updates simply for general updates, users can easily do that themselves with an upgrade. > > > Is there a process to upgrade from one set of packages to a newer > > > set? ie from 2013Q4 to 2014Q1 or 2014Q2. > > > > The best procedure is always to provision a new image, that will give > > you the most complete set of binary package updates as well as image > > changes all integrated together. > > > > In-place upgrades can be fraught with peril and we make no guarantees > > that they will work, especially when running software which requires > > care when upgrading such as PostgreSQL. However if you wish to > > proceed with this method then updating the repository in > > > > /opt/local/etc/pkgin/repositories.conf > > > > and doing a 'pkgin full-upgrade' may work for your use-case. > > > > Ok, not ideal, but workable given that OS containers are light weight. > Promotes the ideal of one service per container, and using automation to > speed up redeployment. Loses the benefit distributions like Debian/Ubuntu > get with testing and scripts to make the upgrade process easier. Indeed. Even if we had the resources that Debian/Ubuntu have and thus could provide a better upgrade experience, I would still advocate the reprovision model as it enforces better infrastructure. -- Jonathan Perkin - Joyent, Inc. - www.joyent.com ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
