<p dir="ltr">Storing the closure in built-using sounds like the correct solution to me.</p>
<p dir="ltr">   Paul</p>
<div class="gmail_quote">On Apr 5, 2016 5:47 PM, "Florian Weimer" <<a href="mailto:fw@deneb.enyo.de">fw@deneb.enyo.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Martín Ferrari:<br>
<br>
>> The alternative is to rebuild reverse dependencies as needed.  I can<br>
>> see two challenges with that.  Right now, the Built-Using field only<br>
>> records the source versions of the *direct* dependencies (based on the<br>
>> dh_golang manual page and a few examples I looked at).  If a critical<br>
>> update happens farther down the dependency chain, a tool based on<br>
>> Built-Using will not mark the top-level package as a rebuild<br>
>> candidate.  When performing the rebuild, it is possible to compensate<br>
>> for that by rebuilding everything that has an outdated Go source<br>
>> package in its Build-Using field, iteratively, until we reach a<br>
>> fixpoint.  But this does not currently work because the -dev packages<br>
>> do not contain Built-Using information.<br>
><br>
> Actually, I had not noticed this before. I have been including the<br>
> built-using field in control files, assuming it will end in the binary<br>
> package too. Maybe we can try to fix this?<br>
><br>
> Alternatively, the built-using field could include the closure of all<br>
> transitive dependencies, although that might explode in size...<br>
><br>
> In any case, we need to take into account that a security fix in a<br>
> library usually will not require security uploads to intermediate<br>
> dependencies.<br>
<br>
We currently need these intermediate dependencies to discover all the<br>
affected applications.  So perhaps dh_golang needs to construct the<br>
transitive closure, instead of listing just immediate build<br>
dependencies.  If we don't want to put this information into the<br>
Packages file, maybe we can keep it in the separate debuginfo<br>
packages.<br>
<br>
>> It does not seem possible to determine rebuild candidates based on<br>
>> Built-Using alone, building the transitive closure after the fact.  It<br>
>> may have changed between the original application build and subsequent<br>
>> library builds.<br>
><br>
> What if we build the transitive closure and discarded any arch:all<br>
> binaries from the rebuild?<br>
<br>
Anything is possible with dak support.  But it's better not to count<br>
on it and rebuild only what we actually need to ship.<br>
<br>
>> Unrelated to all that, we cannot currently perform binNMUs in the<br>
>> security archive because it does not contain a completely copy of the<br>
>> main archive.  I'm not sure if there are good approaches to deal with<br>
>> this yet.<br>
><br>
> So this would be an argument for keeping the status quo and just<br>
> rebuilding applications manually with a sourceful upload?<br>
<br>
Then we absolutely have to minimize what we rebuild.<br>
<br>
Keeping the status quo is barely acceptable for this aspect, but there<br>
is no status quo to keep for the discovery of packages which need<br>
rebuilding.  We just don't have that capability right now.<br>
<br>
_______________________________________________<br>
Pkg-go-maintainers mailing list<br>
<a href="mailto:Pkg-go-maintainers@lists.alioth.debian.org">Pkg-go-maintainers@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers</a><br>
</blockquote></div>