"stable" ports?

Matthias Andree matthias.andree at gmx.de
Tue Mar 30 11:55:05 UTC 2010

Am 30.03.2010 09:18, schrieb Garrett Cooper:

> There is one important note to make:
> Many times you're forced to upgrade packages because of ABI breakages,
> etc. What would happen if there was a CVE assigned for PNG tomorrow
> (like there was for JPEG a year and change ago) where mass changes
> were required of 1k ports -- you could either have to bump the
> versions or patch _every_ single port like Dirk has been doing for the
> past week and a half (and is still doing... also with other folks'
> help thankfully -- poor guy).

Well, a security fix usually does not mean you're breaking ABI.  The ABI break
would be caused by a design flaw in the application that cannot be fixed any
other way, or by lack of backports of the fix to the old ABI version, so you're
forced to use the new ABI.  To complicate matters, using "stable" versions is
exactly the trigger for the latter situation: your using an older than the
latest version is what creates the need for backporting the fix to the "stable" API.

> Furthermore, people could check out packages with RELENG_* tags, and
> maintainers could use their best judgment to tag the files appropriate
> to the change being committed?

I don't think this proposal is useful. Technically it would work, but socially
it wouldn't. Why?  RELENG_* tagging would require that port maintainers oversee
the implications for all supported FreeBSD releases, possibly run tinderboxen to
test (and thereabouts) and would likely scare away maintainers.  Not exactly
what we need.

> Also, another idea that was briefly underscored that I (and other
> folks more importantly) like is that release branches should only be
> updated for security releases. I admit, this is a pain in the rear
> with large / sweeping commits (JPEG/PNG anyone :/?), but at least it
> would ensure that stability is largely maintained.

Basically you'd try to hold off on the "large/sweeping commits" for those
branches and backport.

How about if we create a new port if the ABI or API change in incompatible ways?
As in: jpeg.(N-1) is kept around for compatibility with ports that don't support
jpeg.N (either ABI or API wise) and slowly phased out later.  This takes care of
the libraries.  Open issue: how to handle includes.

This approach (remotely) resembles what the (regexp) database/db[34]. ports are
doing, with some magic in Mk/bsd.database.mk to allow for picking the incurred
DB version semi-automatically.

Matthias Andree

More information about the freebsd-ports mailing list