<div dir="ltr"><div dir="ltr">On Thu, May 14, 2020 at 1:55 PM Morten Linderud <<a href="mailto:foxboron@archlinux.org">foxboron@archlinux.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, May 14, 2020 at 01:39:57PM +0200, Arnout Engelen wrote:<br>> I don't think the buildinfo of the initial build should be a required input<br>
> for a rebuilder.<br>
> <br>> Now of course I know in practice it can be logistically convenient to use the<br>
> buildinfo from the initial build as input for the rebuilder. I'm not saying we<br>
> should forbid this. But I think we should design our standards / file formats<br>
> in such a way that we do not *require* rebuilders to have access to<br>
> information from the initial build. For example, triggering a 'rebuild'<br>
> whenever a new version is tagged in source control could in some cases be a<br>
> valid approach as well.<br>
<br>
This is an implementation detail, isn't it? A buildinfo wouldn't be required if<br>
you are in an environment where the build environment doesn't change. But in<br>
many cases, this isn't the case. Dependencies we pulled could have new versions<br>
which could very well interfer with the build. And if we don't have the<br>
buildinfo file at hand, how would we know what introduced the change?<br></blockquote><div><br></div><div>I think we are in agreement: I was trying to explain why I think rebuilders</div><div>should publish their resulting buildinfo, and while adding the rbvf concept</div><div>proposed above can be useful, it should be shared along with the buildinfo,</div><div>rather than instead of it.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm unsure if you are proposing a rebuild, or argueing for multiple seperate<br>
builds of the same package at the same point in time. The latter is beside the<br>
goal of a rebuilder currently and would in any case be a CI/CD feature of the<br>
given distribution.<br></blockquote><div><br></div><div>I'm not proposing any changes/rebuilds of existing infrastructure.</div><div><br></div><div>I'm mainly arguing that if we introduce a new concept/file format (the rbvf</div><div>proposed above), we should be careful it won't prevent us from doing<br></div><div>useful things (like indeed running multiple separate builds of the same</div><div>package at the same time, or running a 'rebuild' without access to the</div><div>buildinfo from the original build) in the future.<br></div><div><br></div><div><br></div><div>Arnout <br></div></div></div>