Bug#928026: technical solutions enabling binNMUs in the security archive (support of golang packages)

[Ansgar]

Paul Gevers writes:
> 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?

I though about importing the full source to security-master already for
a different reason: `Built-Using` leads to a similar problem as binNMUs
in that uploads require source that is not already present in the
archive.

It is not necessary to push all sources to the public mirrors.

> 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?

That doesn't work as dak doesn't try to keep secrets.  There are various
ways information would be leaked about embargoed issues (mails,
database, web interface (rmadison), ...).

I personally also don't find it too bad to have a fallback: if one of
the hosts is broken at the same time we have to release a critical
update, we can still do so by publishing via the "wrong" archive.

Ansgar

Bug#928026: technical solutions enabling binNMUs in the security archive (support of golang packages)

[Paul Gevers]

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.



signature.asc
Description: OpenPGP digital signature