Bug#793667: #793667: forced depends (instead of recommends) using blends-dev

[Petter Reinholdtsen <pere@hungry.com>]

[Andreas Tille]
> Since a long time I'm wondering whether we should craft tasks files to
> express what we "really" want (like specifying mostly all dependencies
> as "Recommends" and leave the "Depends" for what we really mean as
> Depends.  Since there are the frequently discusses drawbacks and
> compatibility issues with the current tasks files this is nothing that
> should be done quickly.  So for the moment "post-processing" of the
> d/control file in the proposed manner should provide a quick (and
> hopefully not to dirty) solution.

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.

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.

-- 
Happy hacking
Petter Reinholdtsen