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

[Ximin Luo]

Tobias Hansen:
> [..]
> 
> 
> The reason that singular doesn't migrate is that sagemath 7.4 has
> depends like
> 
> singular (<< 1:4.1).
> 
> I don't know however what is the difference between pynac and eclib that caused pynac to migrate but not eclib. They both have a new soname.
> 
> One solution to prevent premature testing migrations would be to add maximal versions for dependencies (like the singular example above) to sagemath.
> That would mean that before migrating a bunch of updates for a new sage version from experimental to unstable,
> we would add the maximal versions to the old sagemath in unstable and wait for this to migrate to testing.
> It's a bit annoying though.
> 

Yeah, I don't think we should resort to maximum versions, that makes upgrading far too annoying.

I asked #debian-devel and the explanation why pynac migrated is that there are special exceptions in the britney script for section "libs" packages, called "smooth updates". This feature is to make large transitions easier and is described here:

https://nthykier.wordpress.com/2011/12/27/handling-transitions-with-smooth-updates/

There's a hint of it in britney's output: https://release.debian.org/britney/update_output.txt

Removing packages left in testing for smooth updates (2):
  libpynac2: i386 amd64
[..]
skipped: -libpynac2/i386 (0, 0, 1)
[..]
skipped: -libpynac2/amd64 (0, 1, 0)
[..]
List of old libraries in testing (2):
  libpynac2: i386 amd64

Otherwise, what I said earlier is correct, it just doesn't apply to pynac due to this "smooth updates" exception. 

The reason this exception didn't apply for eclib is that libec2 was mistakenly put in section "math". However libec3 is in section "libs" and this logic will apply when it would replaced by libec4 etc. [1] defines which sections apply, atm it is "libs oldlibs".

As for singular, you noticed sagemath depends on non-libs too - singular, singular-doc and libsingular4-dev, this is in section "libdevel" which isn't affected by the "smooth updates" exception.

It's true that the "smooth updates" logic will cause sagemath-testing to be not buildable via a testing chroot, but for Debian release purposes:

<mapreri> nearly nobody cares that stuff stays buildable in testing when we are not about to release

so that's why they have that exception in the first place. They do take care of these things just before an actual release, e.g. I assume someone looks at britney's output and makes sure there are no "list of old libraries" or else files bugs for them.

X

[1] https://anonscm.debian.org/git/mirror/britney2.git/tree/britney.conf#n79

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git