Quoting Julien Cristau (jcris...@debian.org): > > I'm not sure that belongs to upstream, again. We should refocus on our > > point, here: D-I. I'm not interested in changing things upstream, or > > even changing the way you deal with them in the standard console-setup > > package. You're certainly handling things the right way. > > > I think this is the absolute wrong way to go, fwiw. Making things > significantly different in the installer means more maintenance > overhead, instead of improving things for everyone and sharing the
There seem to be some misunderstanding here. I don't necessarily want to make things different. The point is trying to keep the use of c-s by D-I sustainable, particulrly in terms of size and memory impact. The very big number of variants brings in a lot of strings....and, potentially, a lot of translated material. That will mathematically make the size impact of D-I grow up exponentially over time. That is a concern. Of course, efforts were made to minimize this and this is really welcomed, for sure. But I still need to be convinced that this will be enough. Again, my proposal is not necessarily changing the way c-s works....but finding a way to have it present much much less variants to users so that it's less confusing for them (usability reason) and has less size impact on D-I (technical reason). I am not specifically favouring a given option, here. I imagined a way to do this (that involves manual maintenance, which I thinks is sutainable) but that may not be the only option. Anyway, I haven't proposed any implementation and I don't know if I'll be able to do so..:). Moreover, I haven't described very precisely what I imagine. In short, we're basically shaking ideas here...
signature.asc
Description: Digital signature
