[RFC] Why FreeBSD ports should have branches by OS version

Vlad K. vlad-fbsd at acheronmedia.com
Fri Jun 23 08:38:32 UTC 2017

On 2017-06-23 10:26, demelier.david at gmail.com wrote:
> Release branches won't have many maintenance except individual bug
> fixes when security advisories are found. No backport, no updates.

Nothing prevents the maintainers from doing exactly that right now. But 
you see, there are two kinds of ports in the tree:

1) ports where upstream maintains a concept of LTS
2) ports that mix bug, security fixes and new features in even 
point.point releases

For some (all?) major production software like Apache, nginx, PHP, 
PostgreSQL, MySQL (I think?), Postfix, Dovecot2, etc... #1 applies. So 
for serious production servers this should be easy to maintain as the 
upstream is doing that in the first place.

The problem is then with ports of type #2. And there's lots of them.

Gentoo portage can easily maintain "stable" ports because portage 
doesn't have a single Makefile, it has multiple .ebuild files so 
multiple versions are available under ONE port name, and bumping the 
version while keeping previous ones available is literally just a matter 
of making a copy of the latest .ebuild and fixing the version in it like 
we do with PORTVERSION.

On FreeBSD that's impossible and often ports are separated and version 
baked into the port name. Like www/node from the original post of this 

But again, that's all doable without having to introduce new 
infrastructure. The ports tree as is can be maintained like this and 
quarterly repos would NOT be required. All it's needed is for 
maintainers to keep a stable version and a latest version. There's 
already plenty of ports done like that, otoh postfix and 
postfix-current, nginx and nginx-devel, etc...

Because the BIGGEST problem in maintaining separate "stable" or LTS 
branches is BACKPORTING fixes for ports in the #2 category, ie. those 
that mix new features with fixes, so you have to CHERRY PICK only the 
fix and BACKPORT it to your "stable" branch. And that's even more work 
often introducing NEW bugs.

BTW, the problem of the original post could've been avoided if the user 
only read UPDATING which clearly stated that www/node becomes 7 and 
previous node (6) becomes www/node6.  (20161207) entry.

Vlad K.

More information about the freebsd-ports mailing list