Re: technical solutions enabling binNMUs in the security archive (support of golang packages)
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
Reply to: