[Debian-science-sagemath] Sage 7.6 testing migration blocked by giac

[Tobias Hansen]

On 06/20/2017 03:44 PM, Ximin Luo wrote:
> Tobias Hansen:
>> On 06/20/2017 01:05 PM, Tobias Hansen wrote:
>>> On 06/20/2017 11:55 AM, Ximin Luo wrote:
>>>> Tobias Hansen:
>>>>> On 06/20/2017 10:56 AM, Ximin Luo wrote:
>>>>>> Tobias Hansen:
>>>>>>> Hi,
>>>>>>>
>>>>>>> dependencies of sage 7.6 have now started to migrate to testing, but
>>>>>>> sage 7.6 can't migrate because giac is blocked due to missing builds on
>>>>>>> armel, armhf and mipsel due to #855078. That means until giac can
>>>>>>> migrate, we have a broken sage 7.4 in testing.
>>>>>>>
>>>>>>> Ximin, did you see that there are new comments on #855078? Maybe they help?
>>>>>>>
>>>>>> Hi, I took a look and the build failures look unrelated to #855078. This bug is a segfault on non-x86 64-bit arches, the build failures we're seeing seem like build rule issues, and fixable. I'll take a look later today.
>>>>>>
>>>>>>> Also, any ideas how we can prevent such incomplete migrations that break
>>>>>>> the old sage version in the future?
>>>>>>>
>>>>>> I actually was not expecting giac to built on armhf/mipsel and was surprised that it did before. But if it's too hard to fix, the easy way to force the migration (for this and future packages) is to upload a version that only declares Architecture: amd64 i386.
>>>>>>
>>>>> I meant more generally. This can happen every time we upload a new bunch
>>>>> of packages for a new Sage version to unstable. If we don't get
>>>>> everything to migrate to testing together it can easily break Sage in
>>>>> testing.
>>>>>
>>>> In those situations, if we control the package, we could do similar to what we did in brial (0.8.5-4) and add a Breaks: sagemath (<= XXX) to prevent testing migration, until the newer version of sagemath and all its dependencies are ready to go in.
>>>>
>>>> X
>>> If that works, we should start doing this routinely. But are you sure it
>>> really works? brial 0.8.5-4 and sagemath 7.4-6 migrated to testing
>>> together, but that was because this sagemath version was uploaded after
>>> brial and depended on the brial version.
>> No that doesn't make sense. Seems like it was the Breaks that caused
>> them to migrate together.
>>
> There's some more detailed info here which is where I got that from:
>
> https://www.debian.org/devel/testing
>
> It talks about "breaks" in the general sense and mentions when Depends: gets broken. I assumed this also includes explicit Breaks:, but it doesn't mention this specifically. Unfortunately number (4) and (5) reasons don't get displayed explicitly on the "migration excuses" page.

Even if britney notices conflicts created by Breaks, this is not that
well suited for what we want to do, because Breaks is only for relations
between binary packages, not source packages. For some packages I think
it's not even possible to create a conflict.

Take for example a library, fplll.
No binary package from sagemath depends on libfplll-dev, so it's not
possible to create a conflict by adding "Breaks: sagemath (<< 8.0~)" to
libfplll-dev.
No binary package from sagemath 7.6 depends on libfplll3 (they depend on
libfplll2), so it's not possible to create a conflict by adding "Breaks:
sagemath (<< 8.0~)" to libfplll3.

However, if this fplll package migrates to testing, it's no longer
possible to build sagemath 7.6 in testing.