Ever thought of building your own packages in poudriere?
No, because I've already got a tool that does the job, and I'm not really a "contrib tool of the day" fanboi. Poudriere is relatively new (2012) and I'm not looking for an intermediate step that requires even more time/space/IOPS anyways. Over the years FreeBSD has had numerous things come and go, and having been bitten by various fiascos such as
vinum in the past, I don't care to invest significant engineering effort in possible losers.
We do this from the quarterly ports tree branches.
You are probably well aware that this way you can disable many dependencies via custom options. E.g. no X11 ...
Which you can do for ports as well.
I don't get your point about 11.3 -> 11.4 -> 12.1 BTW. There is no such thing as a release ports tree. At least not in the form of an SVN tag. What used to be on the CDs in the good old days was just a snapshot at the time of release.
Correct, and that's what has been tested to build by the FreeBSD ports team.
Don't you follow at least the quarterly branch for security updates?
To what end? I'm not using ports to create services. I don't really care if there's a bug in a utility that's been installed for admin use. We can't get security "updates" anyways, because the platform is frozen with chflags schg and securelevel set. The platform is an appliance that exists to run services.
I work with a different model than what you may be used to. I suspect you may have logged onto an *IX system somewhere and found something like, for example, three or four different partial Apache installs, two or three different ones from ports (especially back in the day when there were non-SSL and SSL versions) and one done in frustration by hand. This was actually pretty common back around FreeBSD ... 4? ... I wanna say, and there were divergent competing ports that did not do conflict checking. Anyways it was always very entertaining to log into some web server host that had been installed years prior and which had tried to follow FreeBSD and ports updates, because it would be a trainwreck. It was always particularly fun to find when some Linuxhead had gone and installed Apache by hand using paths that were familiar to them, so you ended up with several different httpd.conf files in various places on the system.
Anyways, I find it incredibly painful to have applications spammed throughout the base system. Inside /usr/local/etc, for example, which of those files are needed for Apache, or PHP, or perl? Which have been modified somehow to make an app run?
So I use a different model that isolates apps within their own directories. Traditional UNIX sometimes did this as /opt/${thing}. I typically do it out of root, so a web server might be "/www". /www is its own filesystem on a separate disks. This allows a host to be shut down, fed back into the OS installer, and come back out with a fresh OS build or image. You know that's you're not toasting anything of value because all the important stuff (the app itself) is on its own disk.
What I wonder is: how do they treat upstream updates to e.g. collectd? They cannot just sync but have to merge their local changes again and again and again. That's what I meant by "local copies suck".
I try to do that as little as possible, but especially now with the transition from python26 to 37/38, ports is a mess.
This is one of the reasons it is useful to have fixed points in the ports tree. We have some local patches and maybe a few local ports that get injected back into the ports tree. Because we have a requirement that hosts must be able to build offline, having all of this wired down and having all the appropriate content for /usr/ports/distfiles automatically installed is part of what the local build system here does.
You can try to manage your own fork of ports, and I can imagine that you would experience some ongoing local skull ache if you tried to do this on an ongoing basis for ports that were actually used for a wide variety of services -- this would be a full-time job, I would think.
I suspect that the ports being used by FreeNAS would be more of a fixed list, along the lines of what I'm doing for the base OS, but probably larger than my list, because I'm guessing that stuff like collectd has local changes for FreeNAS. Some of this stuff is just going to take manual effort to maintain, because not all of it will be appropriate to send upstream. Speaking from experience, it isn't that hard to integrate local changes to updated ports *most* of the time.
But it's really frustrating to work out of a constantly changing ports tree that doesn't produce a consistent reliable result. That's the normal reason people fork ports, or do some hybrid strategy such as what I do.
