[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

technical solutions enabling binNMUs in the security archive (support of golang packages)

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]


[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

Reply to: