My concerns with going arch any would be that it becomes slower to make a tasksel change for some pressing concern, and this magnifies any installation breakage, or blockage caused by task dependencies. The same reason we keep debootstrap arch all. Also every divergence between architectures makes it that much harder to test that tasks are working. The same reason we avoid them in debootstrap when we can. Also, if we are going to depend on something linux-specific in a task, we could | depend on the freebsd equivilant too, and that should work with the task being arch all. If there is not a freebsd equivilant, we could | depend on something that documents how to do it the freebsd way. :P However, we mostly don't depend on things in tasks; we Recommend them. And recommends don't care if it's not available on some architecture. I don't necessarily think these are showstopper converns, but they need to be considered, and any alternatives to the problem considered. Re #697890, if we need iw, d-i should install it on appropriate machines. netcfg already installs wireless-tools when the interface is wireless. Not all machines with wifi are laptops, or even desktops, as was noted several times in that bug. Re #697868, I would much rather leave it to the maintainers of desktop environments (and/or Tech Ctte :P) to ensure that they have eg, necessary network-manager dependencies on appropriate architectures, rather than making tasksel need to track that. Reading that bug, the only reason task-gnome is depending on network-manager is to ensure it gets on CD#1. There are other ways to do that, particularly debian-cd's generate_di+k_list is appropriate since netcfg arranges for network-manager to be installed. -- see shy jo
Attachment:
signature.asc
Description: Digital signature