Adam D. Barratt wrote: > In order to ensure that packages marked as "key" for a task remain present > and installable in testing, britney uses a generated "faux" package which > depends on each of the packages. This approach has, with the odd minor > niggle, worked fine for some time but breaks down as soon as the set of > packages involved are not completely coinstallable; this is now the case > due to the gnome-desktop task indirectly depending on gdm3, and the xfce > and lxde desktop tasks depending on gdm. The net effect is that the faux > package becomes useless for the purpose of determining installability of > the set of key packages, as it is itself uninstallable.
That's unfortunate. I doubt that the light desktop tasks will continue to use gdm for too long, as it seems unlikely gdm 2 will remain in Debian. Probably they will be using xdm or some other light login manager. Possibly gdm3. Probably not something that conflicts with gdm3. Co-installability of tasks is also a desirable property in general. > We've therefore been looking at splitting the single faux package in to a > set of faux packages, one per task. This maintains the overall property of > requiring all of the packages to be installable but only requires that the > packages within each task are co-installable; if there are particular > combinations of tasks which are expected / desired to remain > co-installable then we could add further faux packages depending on sets > of the task packages. Before you spend too much time on that, I have been thinking about converting tasksel's tasks back to real packages. Now that recommends are installed by default, it should be possible to make tasks use Recommends for normal contents, and Depends for Key components. This should simplify a lot of things; it would also allow moving maintenance of some/all tasks out of tasksel, and tasksel would then only need to contain a list of task packages. This has been a longterm plan, and one I wanted to discuss more broadly. But I can try to move up the implementation if it avoids duplicate work. -- see shy jo
signature.asc
Description: Digital signature
