Updating less-than-everything with poudriere & pkgng

[J David]

On Thu, Apr 3, 2014 at 11:36 AM, Mathieu Arnold <mat at 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!