Hi Maintainer

The kdeedu package depends on cantor, which due to to the current
definition of key packages [1], pulls several scientific packages;
e.g. luajit, maxima, octave, r-base and scilab into the key package
set, as well as all of their (build-)dependencies, recursively.

The problem for release team is RC bugs in key packages often go
unnoticed, and unfixed.  We are currently working on redefining key
packages, but in the meantime we would appreciate it if kdeedu could
(temporarily) drop the dependency on cantor.

Regards
Graham


[1] https://release.debian.org/key-packages.html

Hey,

Sorry I need more background and understand this in more depth. Cantor is a
package of the kdeedu suite like every other listed dependency.  And from my
point of view it is a very good education software, so why we should remove
it? Because it has a lot build dependencies?
kdeedu is just a meta package to reflect the set of education software build by
KDE... why is this a problem?
I understand that you have currently a issue at your script that defines some
parts as key packages it should not - well than you have to fix your script,
add an override on your side or something else.

I will remove cantor if I understand why you cannot fix your script. Does a
demotion to recommends or suggest fixes the issue too? Is it the only issue in
whole Debian?

regards,

hefee

Hi,

[no need to CC me, I just subscribed to the bug]


We understand that, but as kdeedu is (currently) a key package, all
Depends and recursively all their Build-Depends become key too. The
outcome of what we're working on is that also kdeedu will no longer be
key and would itself get removed for the current situation. So once we
fix our script kdeedu will get autoremoved from testing too (and no
longer depending on cantor would prevent that).


Nearly. Several of its (transitive) Depends and Build-Depends are RC
buggy and are causing migration problems for other packages too because
of the nature of their state (32 bit and big endian incomplete removal).
It's clearer for everybody involved if we can remove the set from
testing such that people don't need to investigate as much, saving
bystanders from wasting time.


Because it's using Depends and is key itself. In my opinion, it should
use Recommends instead of Depends, but I'll not fight for that.


The current problem with adjusting the key package set calculation is a
social one and not a technical one. That's why it takes (a lot) of time.


As referred to above, absolutely.

No, but an important one for the Release Team. We already burned a lot
of energy on the situation where the meta-kde/cantor situation can
relieve us a bit.

Paul

Hi hefee

I trust that Paul answered your questions satisfactorily.  Is anything
else needed in order to make progress here?

Regards
Graham