On Thu, 2004-12-16 at 20:22 +0100, Jacek Konieczny wrote: > > - przekodować wszystko na UTF-8, dorobić do `rpm -q` przekodowanie > > utf->locale i stwierdzić że pierdolimy kompatybilność z legacy rpms > > to właśnie proponowałem. Znaki które się nie przekodują zostają bez > zmian.
Raczej nie znaki tylko całe teksty (1. trudno będzie zaimplementować częściowe przekodowanie stringa, 2. zrobi się groch z kapustą -- mieszany encoding w jednym stringu). Jeśli o mnie chodzi to może tak być. Czyli plan byłby taki: - ogłosić, że w specach PLD company standardem jest UTF-8 - dorobić do librpm przy odpytywaniach przekodowanie stringów z UTF-8 na locale jeśli jest wykonalne, bez zmian jeśli nie jest; udokumentować że rpm -q dla starych speców może zwracać śmieci (chociaż w 99.9% nie będzie) - dorobić do rpmbuild albo buildera (raczej rpmbuild) sprawdzanie, które będzie marudzić jeśli taki dostanie speca nie-UTF-8 (#def marudzić: docelowo odmawiać budowania (z możliwością override ofkorz), żeby buildery nie produkowały paczek obsolete) - spytać havnera czy chce UTF-8 w Ac; jeśli nie chce, poczekać na rozbranchowanie HEAD<->AC-branch - przekodować z automatu spece z -rHEAD, -rDEVEL i ew. -rAC-branch Takie rozwiązanie wszystkim pasuje? -- Paweł Sakowski <[EMAIL PROTECTED]> PLD Linux Distribution _______________________________________________ pld-devel-pl mailing list [EMAIL PROTECTED] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
