[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
