Date: Tue, 30 Mar 2010 13:55:01 +0200 From: Matthias Andree <matthias.andree@gmx.de> To: freebsd-ports@freebsd.org Subject: Re: "stable" ports? Message-ID: <4BB1E695.2020104@gmx.de> In-Reply-To: <7d6fde3d1003300018gf395446g703cd287c6265a76@mail.gmail.com> References: <hoqikd$o2h$1@dough.gmane.org> <20100329172753.GB39715@wep4035.physik.uni-wuerzburg.de> <hoqrtp$u16$1@dough.gmane.org> <7d6fde3d1003300018gf395446g703cd287c6265a76@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BB1E695.2020104>