Hi all, [@ftp-master: we're discussing the biggest blocker for picking a buster release date] TL;DR; With this mail I'd like to ask technical background and/or reasoning of why the security archive can't do binNMUs for packages that weren't sourcefully uploaded there and to search for concrete potential solutions (I assume there are more) to solve the technical problem of binNMU-ing in the security archive. On 08-05-2019 18:33, Shengjing Zhu wrote: >>> 2. binNMU without full source upload for security-master. >>> >>> It's still not possible, and I don't know there's any effort to >>> change the dak. I am all to new into this business, so ignore my ignorance and please educate me on any mistake. Can somebody please try to explain what the exact problem is or point me to documentation or earlier discussion that do that? I'll try to write down potential descriptions as I see them (from quite a bit of guessing). IIUC from this thread so far, ftp-master and security-master are two separate archives [1]. The security-master archive only contains sources and binaries that were uploaded to security. A potential solution to the problem at hand seems to be to sync all sources from ftp-master into security-master, but I guess that is undesirable because of the massive size increase of the security archive in that case. If this is going to be the solution, is this still dak domain? Another solution already raised by Shengjing is to merge the archives. I *guess* that is undesirable due to the fact that the security archive often has embargoed sources and binaries. Am I right there? Another direction, as I am wondering: when packages are build for the security archive, the binary packages from the regular archive are available to the buildds, right? So is the problem really that the security archive doesn't have the sources, or could/should wanna-build (or the code really responsible for creating the proper binNMU input) be enhanced to support this use case with the archives as they are? I have been thinking that code could be made to do the required stuff out-of-band and basically do sourcefull uploads automatically when required for a set of packages. It feels like a great hack, but I guess such a tool could cover the time until the archive tooling can properly support it. [Here your solution direction] Paul [1] I wonder how that matches with the drawing on https://wiki.debian.org/DebianDak as that suggests that the security archive is just another pool like unstable and testing.
Attachment:
signature.asc
Description: OpenPGP digital signature