Re: tasksel vs. trixie?

Cyril Brulebois <[email protected]> Wed, 28 May 2025 23:17:52 +0200

Newsgroups	gmane.linux.debian.devel.cd,gmane.linux.debian.devel.release,gmane.linux.debian.devel.boot
Organization	Debian
Message-ID	<[email protected]>

Paul Gevers <[email protected]> (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 ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (application/pgp-signature, 833 B)