ffmpeg port

[Adam Weinberger]

On Thu, Jul 11, 2019 at 7:18 AM David Demelier <markand at malikania.fr> wrote:
>
> Le 10/07/2019 à 13:59, Jan Beich a écrit :
> > Why not use binary packages? Or why not build a quarterly branch?
> > Or does anyone have better ideas?
>
> Unfortunately quarterly branches do not solve anything. They are just to
> short to have any benefit. Let say you build a package in January and
> then you don't touch your system for a while. In September, you realize
> you need another port but your local ports also have vulnerabilities.
> Now you have to update by changing the quarterly branch since others are
> no longer maintained. Then, you may have some local ports that will be
> upgraded to a major version which can be undesired for a production
> server. This happened to me a while ago when I had to run an old version
> of nodejs for an old version of etherpad, after an upgrade the new
> nodejs version was no longer compatible and I needed to install node6
> port quickly (hopefully it was available !).
>
> This can be very frustrating since FreeBSD is a rock solid server OS
> that comes with strong compatibility conventions in releases versions
> but provides a ports tree in a rolling release fashion that do not match
> the base version (unlike OpenBSD does). Then you have to carefully check
> each time you need to update your ports that you won't break your system
> (like many do with Arch, Gentoo, etc). IMHO, FreeBSD definitely requires
> a per-RELEASE branches of ports that contain only bugfixes/security fixes.

Hi David,

This is a concept that we grapple with continuously, both here and on
internal lists. The fact of the matter is that we simply don't have
the personpower to maintain more than two concurrent branches (and, by
some estimation, more than one).

We made the decision a long time ago (whether intentional or de facto)
that the best way to ensure consistency was to provide one branch
where ports were always kept up-to-date. There is no denying that this
underserves environments where stasis is paramount, but it provides
the greatest benefit to the greatest number of users.

There are ideas being worked on that would improve CI to bring a
greater degree of stability to head, but would not directly benefit
the deployment scenario you're describing.

We really would love to be able to provide release or LTS branches,
but it simply comes down to resources. We'd need a few people working
in paid positions to manage RE environments. The FreeBSD Foundation
(which underwrites a couple very selective paid positions) has
prioritized development of new technologies to keep FreeBSD
competitive over third-party software backporting.

# Adam


-- 
Adam Weinberger
adamw at adamw.org
https://www.adamw.org