[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

"tasksel arch any" vs. "keeping track of n-m in debian-cd"?

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).


Attachment: signature.asc
Description: Digital signature

Reply to: