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

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

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.


Reply to: