Paul Gevers <elbrus@debian.org> (2025-05-28): > I think it's like this (pkgsel doesn't declare task-*desktop dependencies > AFAICT): Right, it could never express such relationships: pkgsel is a udeb, running tasksel (a deb) in /target, which lists/proposes a subset of its binaries (all debs) depending on the context. > d-i -> debian-edu-install -> debian-edu-config -> education-tasks -> tasksel > (and as tasksel comes from src:tasksel, all binaries from it are > automatically key [1]). Right, the edu indirection looked like a weird thing but I couldn't find anything else/more obvious. > I would *love* to avoid having all the desktops (and what they pull > in) in the key package set, but I also don't want to do that while > making your work harder without being aligned on what both sides > expect from that. I think now is not a good moment to change the > definition of the key package set. Graham and I have been discussing > different definitions already, but that's for forky. Alright. I feel a little sad for Lomiri and Phosh maintainers but I'm fully aware the timing (let's say on my part) looked way off already… and considering we would need to adjust the logic around key packages to accommodate these additions, at this stage of the release cycle, that actually feels very wrong indeed. Thanks for your feedback and for your explanations, much appreciated. Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature