Date: Thu, 3 Apr 2014 13:52:05 -0400 From: J David <j.david.lists@gmail.com> To: Mathieu Arnold <mat@freebsd.org> Cc: freebsd-questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Updating less-than-everything with poudriere & pkgng Message-ID: <CABXB=RSbZkkZk8JTAiH_9_=YrYDeaJJW1Dq0rFzVr2Lky8e6%2Bg@mail.gmail.com> In-Reply-To: <891ACB1137F7FAFFFFAF9A3A@ogg.in.absolight.net> References: <CABXB=RSgfe=nS=tTGd7kFQ4fcGASJCZYaZt9nPGCY=XnX9cTEA@mail.gmail.com> <91FF893BBE05EEFA2894EED9@atuin.in.mat.cc> <CABXB=RQ72AyFp_yC-UHbbZZwTFJnmWuq-UprZ3Tj0c0NM_w2AA@mail.gmail.com> <891ACB1137F7FAFFFFAF9A3A@ogg.in.absolight.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 3, 2014 at 11:36 AM, Mathieu Arnold <mat@freebsd.org> wrote: > Something built for perl 5.14.0 will work with perl 5.14.5.a6_7. This is one of those things that's true most of the time. And on those occasions when it isn't, the fallout is spectacular. It does not come up more often because poudriere does such a good job protecting against it by ensuring that whatever depends on perl is also rebuilt whenever perl changes. What we are trying to do is stop perl from being rebuilt just because we are building something way down the line that depends on it. > If a port > that needs Perl has changes introduced from the Perl update, it will get a > portrevision bump. This problem is more about the opposite case, where Perl changes out from under a port that uses it. Perl got singled out as my example simply because when speaking about the FreeBSD "ports tree" it is the closest thing there is to a root. Another example would be apr. Apache has a security issue -> rebuild apache -> poudriere builds a new version of apr -> apr revs its shared library version -> deploy fix -> unrelated port subversion (not rebuilt) abruptly quits working -> torches and pitchforks. Of course in that case it's not as big a deal because there aren't tens of thousands of ports that depend on apr so, provided you realize apr is getting updated, you can probably find them. Which is fine. Unless the new version of subversion has compatibility issues of its own your developer team isn't ready to deal with. All because Apache has a segfault when logging truncating cookies. Although there's not a "build this, and it's dependents, and it's dependencies' dependents" option either, so you are still pretty much stuck building everything if you want to make sure you found them all. Then again, Apache also depends on perl... The net effect of all of this is that even if you do take 24 hours and rebuild all the ports that depend on perl because of that foobar vulnerability, including bazqux, you *still* end up pissing off the bazqux users because it rev'd bazqux from 1.5 to 2.0 and 2.0 isn't backward compatible. And the people using bazqux don't take "well foobar had a security issue" as a reason for disrupting them, because they don't care one whit about foobar. It's definitely a rock-and-hardplace situation. It's not clear that an ideal answer even exists, but it would be nice to get a little bit closer. Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABXB=RSbZkkZk8JTAiH_9_=YrYDeaJJW1Dq0rFzVr2Lky8e6%2Bg>