Joey Hess <joeyh@debian.org> (07/03/2013): > 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. I'm not sure I see why. > 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. A wildcard like linux-any isn't exactly the same thing as random 31-bits arch restrictions. Basically, both linux & kfreebsd need testing, which we already need anyway… > 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. Too many things kfreebsd still lacks anyway… > 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. I have no strong opinion about this one right now. > 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. I know you're joking but that maintainers vs. tech-ctte was insane already, so I'd rather adjust d-i (through tasksel) to make sure we have decent networking support in the installed system. Delegating such things to debian-cd seems like the wrong way to fix it, but let's see what Steve thinks of it (personally, I'd hate to have to keep track of such things in debian-cd). Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature