Well, "dangerous" as crossgrader is or may be, I still think it's at least generally less dangerous than manually doing cross-grade operations.
Hopefully someone will step up to maintain it? And perhaps, at least at present, it's (nearly) outlived its (most) usefulness? I think most have used it for i386-->amd64 crossgrades. And with >=13/trixie not having i386 kernels, the need may mostly be fading, and for those doing crossgrades on <=13/trixie, and especially <=12[.x]/bookwoorm, they'd probably use the version from that release anyway. May be difficult to get usage estimate/guess, and notably for other crossgrade capable architecture transitions. There is popcon data, but many that install crossgrader at all may only do so on a rather to quite temporary basis, and may remove/purge it after, so might never report it, or only for short period. Anyway, I'm not DD/DM, so not in position to adopt it. But I can update the wiki page https://wiki.debian.org/CrossGrading as changes may warrant. And regardless what happens with the package for >=14/forky, wiki page should remain, as folks do still occasionally need/want to do crossgrading on older releases - even much older, and the wiki page covers that, including release(s) before crossgrader package existed. And, looking again at #1114664 (and yes, technically certainly warrants important, perhaps serious?), though technically it is a bad bug, it's also highly probable that most all using it will easily be able to determine and work around the issue and/or readily also be looking at work-around information (notably mentioned on #1114664 and also well covered on https://wiki.debian.org/CrossGrading ) And maybe at some point someone (maybe even me) might supply a (suggested) patch that would fix the issue. Thanks for the update on the situation! references: https://wiki.debian.org/CrossGrading https://bugs.debian.org/1114664 On Sun, Oct 11, 2026 at 12:47 PM Alexandre Detiste <[email protected]> wrote: > > Disclaimer: I did manual cross-grading before, > by hand, not knowing of this tool. > > If no-one step in to maintain this native package doing dangerous operations, > it's better to drop it altogether. > The autoremoval from Testing is a step in the direction.
