On 1/17/20 6:55 AM, Sam Hartman wrote: >>>>>> "Johannes" == Johannes Schauer <josch@debian.org> writes: > > Johannes> or have a mechanism that allows maintainers to tell buildds "please build this > Johannes> source package with build profiles X and Y enabled". That would then build the > Johannes> binary packages necessary to do a full build in a second upload. > > That doesn't help. > > If I need version y+3 of rustcc to build y+5 of rustcc and only y is in > the archive, no build profile is going to help me. If I'm following correctly: The packager would use rustcc >= y+3 (in practice, likely rustcc y+5) to locally build rustcc y+5 and then do a binary upload. But if dak (or whatever, I'm not so familiar with the server side here) throws away the binary, then we're sunk. So there needs to be a way to note that the binary needs to be kept. Assuming I'm on the right track, here are a couple of questions: In such a case, would the source package have a Build-Depends of >= y+3? It seems like it would. Could that be the way to indicate a bootstrap upload? In other words, if the package has a Build-Depends on one of the binary packages it produces that is _not_ satisfied in the suite it's being uploaded to but is satisfied by this upload, then it's a bootstrap upload, and the binaries should be kept. This would avoiding adding a new field for this and would ensure the Build-Depends are set correctly in bootstrapping scenarios. Regardless of how the "keep the binaries" flag is implemented... should the uploaded binary be published, or should the package be rebuilt? I think I'd argue for the latter. The uploaded binary package should be installed on the buildd and then the package should be rebuilt from source, with _that_ result being put into the archive. This doesn't protect against the trojaned-compiler problem, but it does at least ensure that the package builds from source. -- Richard
Attachment:
signature.asc
Description: OpenPGP digital signature