Prośba o usunięcie zasobów Ti spod ftp.pld-linux.../branches

Marcin Krol hawk at pld-linux.org
Tue Oct 25 18:54:47 CEST 2011


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


More information about the pld-devel-pl mailing list