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