Re: #793667: forced depends (instead of recommends) using blends-dev
Petter Reinholdtsen <firstname.lastname@example.org> writes:
> The tasksel description files have a "Key" concept, which if I remember
> correctly is packages that must be available for the task to show up.
> As such they behave a bit like depends for metapackages, where the
> metapackage is uninstallable if some dependency is missing.
> Perhaps we can introduce a Key: keyword in the blends task files and map
> it to Key: in the tasksel description file and depends in the
> metapackage? It would avoid breaking existing blends tasks and give us
> a way to enforce that a package is pulled in during upgrades.
We could map the (new) "Depends:" packages in the task to the Key:
list in the debian-<blends>-tasks.desc file (and to Depends: in the
metapackage itself). This would prevent uninstallable tasks from showing
> It would also introduce a hard dependency between a package and the
> task, exactly the kind of link we wanted to avoid when deciding to make
> all task packages recommends or suggests, so it should be used with care
> to avoid getting a task thrown out of testing needlessly when some nice
> to have but not vital package is removed from testing.
The proposal for debian-edu does exactly this: introduce a hard
dependency, with all its advantages and drawbacks. When looking into the
bug, this seems to be the intention.