A wspomniane przeze mnie biblioteki też się łapią? Bo na serwerach żadne z powyższych mnie nie interesuje. Innymi słowy - czy TLD kieruje w desktop?
TLD ma być i na serwer i na desktop przy czym dla mnie osobiście ważniejszy jest serwer. Do desktopa się nie mieszam, ale skoro są osoby które chcą go aktywnie rozwijać to nie mam zamiaru tego w żaden sposób blokować.
No a co dopiero do 6... A ile aplikacji nie działało z pythonem 2.7?
Dlatego python 2.7 jest u nas w aktualnym devel dopiero :-) Stable niestety stało się archaiczne głównie z powodu braku mojego czasu na przeniesnie infrastruktury. Teraz to nadrabiam choć nie tak szybko jakbym sobie tego życzył.
Czyli to ma być takie bardziej stabilne w sensie wersji Th (modulo bcondy co były pod Ti)? Będziecie używali CVS PLD, czy też fork?
To ma być dokładnie to co było w Ti do tej pory tyle, że bardziej uporządkowane z osobną wersją devel do spokojnego przebudowywania w oparciu o nowsze wersje bibliotek. Zdecydowana większość paczek będzie budowana z CVS PLD. Do naszego GITa trafią tylko paczki, których nie da się dla Ti zbudować z CVSa PLD bez stosowania if'ów w specach, branchowania itp. oraz takie, które chcemy mieć inaczej paczkowane niż PLD (na chwilę obecną tylko KDE4, ale dopiero od następnej wersji devel).
Ale to nie dyskusja, tylko ustalanie faktów;) Myślę, że więcej osób może być zainteresowanych wolniejszymi i bardziej skokowymi zmianami niż mają miejsce w Th, mnie np. interesłuje długofalowa wymienialność pakietów (złamana już w perlu, ale zależy mi na iceweaselu bez systemowego XUL-a). Do tej pory traktowałem Ti jako alternatywne źródło pakietów, które z Th np. już wyleciały, ale jeśli TLD będzie używało własnego RCS-a, to raczej nie będę go używał.
Niestety z powodu konieczności zmiany nazwy z PLD na TLD sporo pakietów przestało być wymienialnych na zasadzie prostego "poldek -i" z odpowiedniego repo. Wspomniany perl i wszelkie jego moduły, gcc + wszystko co ma zaszyte w sobie nazwy kompilatorów (a jest tego trochę) i... chyba tyle. Rzeczy zależne od kompilatorów da się zainstalować i będą działać, ale np na TLD z pythonem z Th nie zbuduje się nic okołopythonowego bo nie znajdzie w systemie pliku kompilatora i686-pld-linux-gcc (w zasadzie można by to łatwo rozwiązać symlinkami... hm... ąż przetestuję w wolnej chwili). Poza tymi przypadkami wymienialność paczek nie powinna ulec zmianie, a co do RCS to jak wspominałem wyżej głownie budujemy i będziemy budować paczki z CVSa PLD. Odforkowanie się w całości nie wchodzi w rachubę, bo jak wiadomo nie ma na tyle mocy przerobowych. Aha, tak Iceweasel jak i Icedove będę rebrandował od nowa w najnowszych wersjach i na pewno nie będą budowane z systemowym XULem :)
Używając TLD stable nic się nie zmieni jeżeli chodzi o pogoń za numerkami czyli nadal bardziej nas interesuje sprawny działający system niż wersja Y paczki Z. W TLD devel natomiast będzie bardzo podobnie do Th czyli jak np. założeniem dla kolejnego snapa będzie GCC 4.8 to trafi on tam niezależnie od tego co zepsuje i ile rzeczy się z nim nie będzie budować. Mimo tego w miarę możliwości do drzewka main w wersji devel nie będą przenoszone rzeczy psujące zależności między istotnymi z punktu serwerowego pakietami.
M. _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
