Solved Maintaining packages with custom options

Hi all,

I'd like to follow the quarterly package repository (because I value stability and reliability over new features), but I need to have a few packages compiled with custom options, and this results in a problem:

Ports does not have a quarterly release, only a "rolling release" of sorts. As a result, when I change the options of one or two programs (which I must from time to time), I am usually forced to rebuild and upgrade hundreds of packages to their latest versions, wasting a fair bit of time, and defeating the point of the quarterly repository.

This seems to be the case with make(), ports-mgmt/portmaster, ports-mgmt/synth, etc.

The only way around this seems to be only updating the ports tree once a quarter, when the quarterly repository is updated, and not updating it until the next quarterly update.

Is there no quarterly ports tree?

Am I missing something? Is there a better way to do this?
 
But why wait so long with updates in the first place? Exploits and such can surface at any given time, they don't wait until things match your update schedule. The longer you wait, the more work will be involved. Just wondering; you are aware of the extra work which is sometimes required as mentioned in /usr/ports/UPDATING?

I dedicate one / two hours every week to keep my FreeBSD servers up to date. And with the help of sysutils/tmux I also don't have to worry about my login session, I can maintain those. So basically I log on, refresh the ports tree, check which updates are available as well as check for any optional update instructions and then set things to work. During compilation time I can focus my attention (most off) on other stuff and leave things at that.

One thing though: this is all fully custom coded. I wrote a few scripts which utilize portsnap, portmaster and pkg (pkg-updating(8) is extremely useful here) and have also instructed Portmaster not to update any mission critical stuff during regular updates.

As soon as mission critical services need updating (think Apache, Postfix, OpenVPN..) then I plan for those in order to anticipate possible moments of downtime. I also don't "just" upgrade these but perform tests and build the packages on a testing environment first and only then make them available to the rest of my servers.

But I'm most certainly not waiting 3 months to perform updates. At most (with mission critical stuff) 2 weeks. So I spot an update for, say, Apache. I then plan a test (and build) on the test environment within that following week, and once that has been sorted out I then schedule the actual update. Sometimes for the next week (all it involves is basically installing an at that time binary package) but at most the week after.
 
But why wait so long with updates in the first place? Exploits and such can surface at any given time, they don't wait until things match your update schedule.
I don't think this has anything to do with an update schedule. Tracking the quarterly branch actually makes sense. The latest ports tree is in constant flux. There's something to update pretty much on a daily basis. But most of these updates have nothing to do with security fixes. By tracking the quarterly branch you get a bit of stability, as the only updates you'll need to do are the security updates(*) and you're not suddenly faced with Ruby going from 2.2 to 2.3. Or Perl moving from 5.18 to 5.20.

(*) Quarterly branches get security updates too. They're not created and only updated once every three months.
 
They do [have a quarterly ports release]. How do you think the quarterly packages are built?
https://svnweb.freebsd.org/ports/branches/2017Q1/

Sorry, I should have been more specific: There is no option, using portsnap, to track a quarterly ports release (I know that it exists). I completely forgot about SVN. My fault. It is of course, in the handbook, and on the synth project homepage.

But why wait so long with updates in the first place? Exploits and such can surface at any given time, they don't wait until things match your update schedule.

It was my understanding that the quarterly release gets security updates, while remaining pretty stable. Which is what I would like. Also, in my case, my work has nothing to do with FreeBSD per se, other than I like to use it, and I would really prefer not to spend hours every week maintaining test/build environments, building, testing and upgrading.

Looks like I'll be switching from portsnap to SVN to have my packages, and ports, follow the quarterly branch.
 
It would make sense to me, to have a configuration file, like the one in /usr/local/etc/pkg/repos/FreeBSD.conf which tells portsnap which ports tree to fetch. But SVN does the job just fine;)
 
Back
Top