Nem, nem egy csomag tört el, még egyszer mondom. Eltört több, tudunk kettőről, meg még lehet egy pár, amiről nem, mert nem használjuk, és aki megszívta, azok közül nem mindenki jelentget bug trackerbe, meg a bbs.arch fórumán, hanem szépen törli, és visszacsapatja a Zubuntut, Debiant, stb.. Ezeket fokozatosan javítják is, csak pár napot kéne még várni, mire feltérképeződik, hogy mely csomagok ezek pontosan, és melyik verzió javítja a kompatiblitást, esetleg csak újra kell fordítani a kódjukat.
Mondom, ne engem ragozzál, mert nem tetszik, amit írok. Nekem sem volt bajom az Arch-csal sok évig, pedig a Testing tárolót használom. Mondom, ez a csomagfenntartó hibája, mert tudja, hogy az új verzióval nem kompatibilisek a tárolókban lévő csomagok. Ennek az lenne a szakszerű menetrendje az Arch szabályzata szerint, hogy ilyen csomag, mint a glibc, előbb a Staging tárolóba kerül be, ezt használva a csomagfentartó újraforgatja a rá dependelő csomagokat is (sokszor ez is elég), ha ezek is készek, akkor ezt az összes érintett csomagot beteszi a Testing-be, ha ott kiállja pár napig az idő próbáját, akkor mehet a stable Core-ba. Itt viszont átugrották ezt a lépést, szívás is lett belőle, de még várni se vár vele, már pattintják is kifelé élesbe is. Ha csak 2 csomag is tört el, amik javítva lettek, de óvatosságra kéne intsen, hogy még pár napig várjanak vele. Nem hónapokat, éveket, csak extra pár napot, amíg még átpróbálgatják a vállalkozó kedvűek Testingben.
A kernellel is szívok, félre ne érts, de az upstream AMD / amdgpu hiba, amit maguk a kernelfejlesztők bénáznak több kernelciklus óta (6.10-6.13), arról az Arch nem tehet. Persze a kernelfejlesztők is kapkodnak, ugyanezt csinálták, kijöttek mindenféle energiagazdálkodási módosítások az amdgpu kernelmodulhoz, az aktuális dev kernel RC-jébe, ott szépen gyűlt velük a tapasztalat, szaporodtak a bugreportok, hogy fagyásokat, és újraindulásokat okoz egy kazal AMD GPU-n, erre nem hogy megjavították, ezzel a kóddal adták ki a stable mainline kernelt is, sőt, még tovább mentek, tudván, hogy rossz a kód, bugos, ennek ellenére visszaportolták a problémás kódot az addig nem érintett LTS kernelágakba is (6.1.x, 6.6.x). Azért azt érzed, hogy ez szemétség, és teljesen felesleges bajkeverés. Pont az lenne az LTS kernel lényege, hogy ilyenektől védjen, abba tényleg csak az kerüljön, ami tényleg annyira tesztelt és stabil kód, hogy nem törik el semmit, a konzervatív LTS disztrókon sem.
Az újraforgatás is rettenet fontos, pár hónapja a saját bőrömön tapasztaltam meg, néhány csomagnál, alock, st, dmenu, stb., amiket AUR-ból, vagy saját kódból forgattam, eltörtek. Ez se bug volt, meg nem is Arch hiba, hanem régi binárisok voltak, kicserélődtek alattuk a függőségeik, de azokhoz nem voltak újra hozzáfordítva. Pedig ez szükséges, nem véletlen, hogy a komoly disztróknál a build szerveren, ha a függőség frissül, akkor újraforgatódnak a rá épülő csomagok is, nem véletlen, hogy a Gentoo is így csinálja, ha jön egy új verzió valamiből, vagy te kapcsolták be/ki egy USE flag-et, akkor az összes érintett csomag, és azok összes érintett függősége újrafordul, akkor is, ha az ő kódjuk nem változott semmit. Ezt tökéletesen tudják az Arch-nál is, alkalmazzák is ezt, kivéve most ez a szerencsétlen glibc maintainer, most nagyon sürgős volt neki, hogy azonnal kitolja az egy szál glibc csomagot a Testingbe, és lusta módon, nem buildelte annak ellenébe a tőle függő csomagokat. Ez okozta a problémák nagyját, de még ebből sem tanulva, most már tolja kifelé élesbe is, úgy, hogy sok minden még mindig nincs az ellenében fordítva. Legalább írná ki a hírekbe, hogy hova siet most ezzel ennyire, kinek a segge ég, hogy annyira hama kint legyen az a 2.41. Mert megérteném még azt is, ha valami szenzációs új feature, vagy optimalizáció lenne benne, hogy nem lehet kihagyni, azonnal kell, annyira király, de ez az eset sem forog fent.