"Ehhez kepest a KDE-bol most havonta jon verzio, raadasul egyikkel sem vagyok elegedett."
Nekem is egyre bugosabb, es regen azonnal javitottak a bejelentett bugjaimat, most eszre se vettek meg oket, valoszinuleg a KDE le lesz cserelve, az nem attol rossz, hogy Gentoot hasznalsz, hanem hogy a Novell meg a Nokia mar nem ol bele annyi human eroforrast sajnos (mindkettot az MS kapta szet).
"Gentoobol egyelore hianyzik a trintiy"
Archban mondjuk van trinity repo
"Aztan ott van meg az, hogy gentoon megszuntek a GLSA-k, a forum hasznalhatatlan lett (gyak. nincs ertelmes informacio, vagy alig talalhato meg), a csomagok kevesbe karbantartottak, mint korabban, stb."
ezalapjan egyertelmuen Arch, egyedul az extra/chromiumhoz valo hozzaallasuk nem tetszett ("nem update-eljuk, mert az osszes dev firefoxot vagy auros Google-chrome-ot hasznal", vagy valami ilyesmi indok volt)
A tavalyi Archos kerdeseidre:
"* Az adminisztracios toolok nekem kicsit kenyelmetlenek, es nem hozzak mindenben az altalam megszokott funkcionalitast (portage/eix/equery/genlop/etc-update/rc-*/stb.). Erosen ugy tunik a forumuokbol, hogy a gentoo hoskorara emlekezteto privat szkriptgyartas folyik ezeknek a funkcionalitasoknak potlasara."
ez egyszerubben megoldhato gyakrolatilag mindig, mint egy gcc-s ujraforditads utani emerge lehalas, teny, hogy nekem is kellett mar bash scripteket irnom desktop hasznalatra. Amugy /etc/rc.conf iolyan egyszeru, mint egy faek, pacman meg szol, hogy mikor kell maunalisan config file-t modositani, mikor rakott fel ujat (pl. "warning: /etc/X11/xorg.conf installed as /etc/X11/xorg.conf.pacnew, es akkor tudod, hova nyulj, ha a regi konfiggal baj van)
"* Bar az arch latszolag megkulonbozteti a fuggosegkent es a kozvetlenul telepitett csomagokat, megsem igazodom el teljesen a dologban, hiszen a "core" installasaval az osszes core csomag kozvetlenul telepitettnek minosul. Es ez igy van - ha jol ertettem - az osszes csoporttal (meta-csomaggal). Ezzel szemben a gentoonal a "system" es a "world" metacsomagok nagyon jol mukodtek. A system csomagok nem valtak explicitte, ha az ember ezt nem akarta, igy jol kovetheto volt a kozvetlenul telepitett csomagok listaja. raadasul ezt mar a toolok is pl. szinekkel megkulonboztettek."
azota a pacman/yaourt ilyen teren eleg interaktiv lett, csoportoknal egyesevel kivalaszthatod a csomagokat ilyen szamozos rendszerrel, kiirja milyen csomagokhoz milyen szamot uss be, de "world" meg "system" metacsomagok szep szinezessel sajnos nincsenek, az emerge marad a szep (de pacman -Ss eseten amugy kiirja, hogy az adott csomag milyen groupban van)
Egy pelda:
2 eve pacman -S kdebase-workspace felrakta a phonon-gstreamer-t, csereltem is le egybol phonon-xinere, es tavolithattam el a gstreamert gyokerestol, mert akkor semmi masra nem kellett. Iden uj laptop -> pacman -S kdebase-workspace interaktiv modon kiirta, hogy 1: phonon-gstreamer 2: phonon-xine 3: phonon-vlc , choose one.
Meg valahol lattam, hogy mar a bash sem feltetel, hanem a virtual "sh" megoldas, ami lehet pl. zsh, tehat egyre jobb a fuggosegkezelese a pacmannek szerintem, es kozben megis user friendly maradt
"* Nem ertem, hogy ha minden csomagnak csak egyetlen verzioja van a repositoryban, akkor hogyan lehet visszalepni egy problema eseten. Elofordulhat tipikusan kernelnel, driver csomagoknal, stb., hogy az uj nem mukodik rendesen. Ilyenkor varhatok amig valaki ki nem javitja? Mi van ha egy rendszeren belul egy adott librarybol tobbfele kell? Mi van a pl. a KDE-vel? Ha valaki nem akar valtani pl. 4.5-re mert hianyzik a PIM belole? Vagy ha korabban nem akart valtani 4.x-re? A fuggosegek miatt egy ido utan ugyis ra fog kenyszerulni az upgradere. Ezt erzem a legnagyobb gondnak. Persze tudom nem kotelezo a repositoryt updatelni, de akkor mi ertelme archot hasznalni."
/var/cache/pacman/pkg -ben utvan az osszes regebbi csomag, pacman -U /path/to/pkg -val barmikor visszarakhato a regi (legrosszabb esetben kernel eseten chrootbol, de nekem erre 2+ ev alatt nem volt pelda). pacman.conf-ban pedig vannak olyan szintaxisok (elore bekommentelve) hogy valamit ne update-eljen.
Meg vannak kulso repok, pl. trinityhez, catalyst driverhez (patchelt xorg+amd-s driver), meg ami pl. nekem kell: -ck patches kernelhez (de sajat custom kernel howto is van "Arch way"), meg szokott lenni mindenfele betatesztelo repo (gnome-unstable, kde-unstable), de ezek a core+extra+communityvel ellentetben nem hivatalos repok, sajat felelosseg kategoriasok
"* A tobb csomagverzionak meg volt egyebkent egy masik nagy elonye, megpedig az ember latta, hogy egy csomagot aktivan fejlesztenek-e. Mar lehetett latni a maszkolt verziokat, es az meber sejthette a frissules utemet."
itt erre a testing repo van, de nem erdemes vele jatszani, legegyszerubb megbizni a fejlesztok/csomagolok donteseben, abbol baj nem lehet, erkezik, ha mar jo (uj kernelnel pl. 1-4 het szokott a testing->core ugras lenni, meg uj xorg is volt, hogy intel driver hibaja miatt csomo ideig testingben maradt)