[arch-dev-public] dependency rebuilds

[Paul Mattal]

When package y depends on package x and package x is updated, there are 
essentially two clean ways to divide up responsibility for rebuilding 
dependent package(s) y:

1) the package y maintainer(s) notices package x in testing and rebuilds 
package y

2) the package x maintainer(s) is responsible to find all packages y and 
rebuilds all such packages y against the new package x

I've seen many variations on how this gets handled over the last three 
or four years as a a developer, and we usually just try to do what makes 
things best for most people, but it's good to have some idea what to 
expect in general. We all want to do what's best for the most people, 
but it's not always clear what that is.

A merit of #1 is that the actual maintainers of the dependent packages, 
who can sanity check and test the new dependency, are involved in making 
sure the packages get built and function correctly against the new 
version of dependent software. A downside is that this is likely to take 
some time-- the dependent package maintainers need to notice the 
dependency update, have time, and do the update properly.

A merit of #2 is that the updates get done quickly. A disadvantage is 
that they may not be done correctly, possibly even introducing uncaught 
security holes or result in data loss. Another disadvantage is that for 
really core low-level packages (like glibc or even something like 
sqlite), the number of rebuilds is potentially huge and the likelihood 
of getting things wrong is even larger, and it will be increasingly hard 
to get people to agree to maintain those low-level packages because of 
the amount of work involved.

How have people generally been approaching this issue and with what 
rationale? As a starting point, in absence of other communication, I 
generally expect developers to rebuild and test their own packages when 
their dependencies are upgraded, but perhaps I'm in the minority.

I think we should be sensitive to the general number and kind of 
dependencies we have on packages we maintain, and make sure to put those 
things into testing to give other developers lots of time to rebuild and 
test against them, but not assume we each have sufficient knowledge and 
experience to rebuild any of the potentially vast spectrum of dependent 
packages with any reasonable certainty they will work.

- P