Control: tags -1 moreinfo Hi Andreas, First off, a huge thanks for the enormous amount of QA work you're doing. It's truly great. Please don't take this reply as a "no", I really just wish to discuss my concerns in the open. On 10-06-2021 19:25, Andreas Beckmann wrote: > mono packaging contains an awful lot of circular dependencies. The biggest > one is [1]. Bugs are open for more than 10 years ... Right. Without a lot of investigation from my side it appears the Debian Mono Group may be a bit understaffed at the moment. I'm CC'ing them nevertheless to allow them to respond. > [1] http://debian.semistable.com/dot/mono-runtime-sgen_testing.png > (copy attached) > > As a "workaround" mono-gac started to mess around with conffiles of > mono-runtime-common, confusing the dpkg database state of the conffile. > => #985066 Noted. Am I correct that the other issues you found and mention below were only found after you tried to fix this issue? In other words, if we leave this (RC buggy) hack in bullseye that the other bugs do not appear? I'm really, really wondering if at this stage of the release we shouldn't just leave this bug in, instead of rushing (albeit piuparts tested) solutions in. Maybe it's best to fix this early in bookworm? > Some background: mono-gac provides gacutil which is called via hooks from > maintainer scripts. The new gacutil does not work with an old version of > the conffile /etc/mono/config from mono-runtime-common => #986275, #986293 > > Thus we need versioned pre-depends and need to reverse the dependency > between mono-gac and mono-runtime-common. (And add a Depends: mono-gac > to all rdepends of mono-runtime-common, only 2 relevant packages) > > To Break the big dependency loop I'm going to drop mono-runtime > dependency from libmono-system-4.0-cil and > libmono-system-configuration4.0-cil - all rdepends of some libmono-*-cil > also depend on libmono-corlib4.5-cil which keeps this dependency. > Then I'm going to move the actual .dll from libmono-corlib4.5-cil to a > NEW package libmono-corlib4.5-core-cil (better name welcome, I think > I'll switch to libmono-corlib4.5-dll) and redirect the > libmono-corlib4.5-cil dependencies from libmono-*-cil on the big cycle > there. > libmono-corlib4.5-cil depends on libmono-corlib4.5-core-cil, so for all > 250+ rdepends outside this big cycle nothing changes, they still get the > corlib+runtime dependency > > We still have several independent dependency cycles between > libmono-*-cil, but these don't seem to cause problems currently. > > I'm attaching both a source and binary debdiff, since dependencies are > going to change ... > > I've run a lot of piuparts install and upgrade tests on these changes > (and will do some more) on amd64 and have stopped encountering mono > related issues ;-) > > If you ACK this, I intend to 0-day NMU this to experimental because it > needs NEW processing. Please prod the ftp-masters to get this actually done. > Then I'll reupload to sid (since the NEW package is arch:all). > > unblock mono/6.8.0.105+dfsg-3.1 > > Andreas > > PS: > I haven't seen any maintainer comment on any of these bugs :-( Hence, explicit in CC now. > PPS: > I have no clue about mono, but I'm confident enough that this patch does > not make the situation worse :-) Yes, but mono is a true key package (not only by the 5% popcon limit as indicated on [2], but also when removing the popcon based key packages; it's needed by meson <- atk1.0 <- d-i), otherwise I might have removed it. Paul [2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature