Julien Cristau:
> On Tue, Feb 7, 2017 at 00:33:04 +1100, Stuart Prescott wrote:
>
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian....@packages.debian.org
>> Usertags: britney
>>
>> [...]
>>
>> <jcristau> themill: the linux source package builds debug packages for
>> things that are built by the linux-signed source package
o_O
I am surprised that dak allowed that in the first place. Anyway, that
is a subject for a different forum.
>> <jcristau> i don't think that was ever considered when i made the "sync
>> testing and testing-debug" stuff
>>
> Does the below look like it's going to explode on us, or otherwise do
> bad things?
>
> diff --git a/britney b/britney
> index 9b29bc1..f33a7f3 100755
> --- a/britney
> +++ b/britney
> @@ -178,7 +178,6 @@ dak_import_debug () {
> WHERE arch.id = debug.architecture
> AND testing.suite_name = 'testing'
> AND debug.package = testing.package || '-dbgsym'
> - AND debug.source = testing.source
> AND debug.version = testing.version
> AND debug.architecture = testing.architecture
> AND archive.id = fam.archive_id
>
> Cheers,
> Julien
>
I say we try it. :)
AFAICT from a quick glance; it should work due to:
"""
AND debug.package = testing.package || '-dbgsym'
AND debug.version = testing.version
AND debug.architecture = testing.architecture
"""
I believe those constrains should adequately ensure that the dbgsyms are
only in testing if the binaries they enhance are present.
Obviously, if you sneeze at the linux binaries OR the linux-signed
binaries in testing, the dbgsym packages will disappear as a side-effect
(the effect is unrelated to the constraint we are removing). That said,
as I understand it, the binaries from these two sources basically have
to be lock-step upgraded anyway, so I do not really see the potential
missing dbgsyms as a (separate) issue.
Finally, if we are wrong, the worst that can happen (AFAICT) is that we
have to re-instate the constraint and the dbgsyms will disappear in the
next run.
In summary: Go! :)
Thanks,
~Niels
