Hi, and thanks for your input Moritz, that's really helpful.
On 28/08/2020 19:48, Moritz Mühlenhoff wrote:
> On Thu, Aug 27, 2020 at 07:16:19PM +0200, Clément Hermann wrote:
>> I'm fine with IRC too. I think the dak implementation would be the best
>> (along with a script or something that can tell which packages to
>> binNMU, but with the proper field set d/control for binaries that
>> doesn't sound difficult).
>>
>> What I'd hope to get from such a session would be possible, acceptable
>> workaround if the dak issue is (as it seems) too complicated to fix in a
>> timely manner.
>
> I think only FTP masters have the necessary insight to answer that.
By "that", do you mean determining if the dak issue is too complicated
or not to fix, or what would be an acceptable workaround for it ?
> The important thing is that in end binNMUs are made, a script which
> in the end performs sourceful uploads would cause too much churn.
Agreed, if that needs to happen is has to be as temporary workaround.
>> For instance, a script that would get all the needed source package and
>> upload then whenever someone needs to binNMU a go package. Or whatever
>> makes security@d.o and release management life easier.
>
> Ideally we'd have a script which accepts a source package name as a parameter
> and the distro to target (like buster or unstable). The output should be
> a list of wanna build commands, like
>
> wb nmu $SOURCEPKG . ANY . $DISTRO . - "Rebuild for $REASON"
Would it make sense to (optionnaly) provide a version for the source
package as well ? The script would then look for packages including the
code with that version or lower. If that's not needed, it's simpler, but
it should be possible.
I'm currently trying to come up with the best way to get the info needed
to get the wanted output.
My initial plan was to have a binary package control field, something
along the lines of XB-X-Go-Built-Using.
It made sense to me, because of the current (mis)usage of Built-Using in
Go packages.
However, if we start from the source package, it might makes more sense
to use a source paragraph custom field, say, something like this:
XS-Go-Built-Using:
The name isn't great in this case (well you do build a source package,
but still), I'm open to suggestions ;)
The idea is to have a new ad-hoc request in dacweb
(api.ftp-master.debian.org) that will allow to have a json with all
packages having this field set, ordered by Suite.
Then I guess it's a matter of parsing the fields to detect wich source
packages are using the package we want to replace, and then do it again
with those packages, until nothing is found (this is going to be some
fun algorithm writing, ideas and suggestions very welcome).
> I think there might be staggered build steps. Like when liba gets binNMUd
> and then libb (which uses liba) needs the same. So ideally the order of
> wb commands emitted should reflect that.
Yes. Hopefully we can come up with something that will avoid to much of
trial and error.
> With that setup in place, supporting Go and Rust updates in stable (and
> the same tool will also be useful in unstable!) should be fine. Shared
> libs would ofc be preferable, but withful thinking doesn't help us either :-)
:)
Cheers,
--
nodens
