Első lépések Gentoo alatt

Jelentem kész vagyok! Nem ez igy még nem igaz még van mit finomítani de nagy vonalakban megvagyok.
Elmondom.
Szal múlt héten eldöntöttem, hogy a gépemen márpedig Gentoo lesz ha törik ha szakad. Egyrészt mert eddig még nem találtam olyan disztribet amivel tényleg elégedett lettem volna, tudtam volna szeretni a hibáival együtt. mindegyiknek volt egy olyan bibije ami nem tetszett.
Slackware - nem szeretek csomagokat külön külön bóklászni a neten
Suse - erőforrásigényes plusz nála párszor rendesen összecsinálta magát
Fedora - na ez teszett mégis volt vele gondom nevezetesen az erőforrásigény itt is, meg lassúnak találtam a csomagkezelést
Debian - ez kitartott egy évig de egy idő után kezdett olyan érzésem lenni, mintha a fél életem guglizással tölteném
Ubuntu - nekem túl csilivili
Elismerem nagyok az igényeim. :) De végre megvan. Az elhatározás, hogy Gentoo-t próbálja már régi de valami mindig visszatartott mégpedig a fordítási időkről szóló rémhírek, bonyolultság.
Szal gondoltam rászánom a hétvégét és Ubuntu le Gentoo fel ha éjszakáznom is kell miatta (kellett, azazhogy elvesztettem az időézékelésem a bütykölésben).
Elsőre persze belekavarodtam és mivel nem szeretem a logikátlan munkát így adtam neki egy második próbát.És láss csodát vasárnap reggelre működő Gnome-om volt estére saját kernel meg minden ami kell.
Elismerem fordításnál nem a leggyorsabb de ezért kárpótol, az hogy cserébe egy maximálisan konfigurálható rendszert kapok. Amire baromi egyszerű feltenni minden nem csak azért mert jól dokumentált, de azért is mert mindenre van csomag és ráadásul a rendszer pontosan tájékoztat ha hiba történt(ami főleg az én saram volt sokszor.)
Nem akarok untatni senkit de most nagyon örülö hogy végre egy olyan rendszer van a kezembe ami stabil ugy működik ahogy én akarom, átlátható,és baromi jó supportja van.
Csak biztatni tudok mindenkit aki gondolkodik Gentoo-ra váltáson, hogy tegye meg mert nem bánja meg. 
(jah ez az első rendszer amin működik a webkamerám kb. 30 órai munkával. Debiannál anno 2 hét googli meg nagy semmi volt …)

( tiger | 2007. 11. 05., h – 16:02 )

A hétvégén én is feltettem, eddig egész jó. :)
---
Ketchup elementál megidézése a sajt síkra

( leeroy | 2007. 11. 05., h – 16:02 )

En ott adtam fel, mikor vegre lefordult vagy 2 ora alatt a firefox, gnome-ba mar bele se mertem kezdeni.

Firefox van binárisba egyrészt de meg tudom neked mondani a részidőket. Kernel nekem kb 20 perc fordítani,xorg kb 2 óra,gnome-light 3 óra,openoffice az húzós az 6 óra.
Nem veszélyes kb 2 -3 nap nem full munkával és van egy rendszered amit onnantól frissíteni kell.
Én is a fordítási idők miatt féltem de télleg nem vészes. :)
---
MSI KT3 Ultra, 1GB DDR, AMD Athlon 1800+, NVIDIA GForce4 MX 440

( pinyo_villany | 2007. 11. 05., h – 16:10 )

"Debian - ez kitartott egy évig de egy idő után kezdett olyan érzésem lenni, mintha a fél életem guglizással tölteném" :D
akkor igy megy lehet hogy az egészet :P igaz gentoo-t nem ismerem, de majd egyszer, ha sok időm lesz ránézek ...

gondolkusan logikszani (R)
katt

( hege | 2007. 11. 05., h – 16:58 )

:) örülök hogy eddig tetszik.

Érdemes néhány kiegészítőt feltenni a csomagkezelőhöz: gentoolkit (equery, revdep-rebuild miatt főleg), layman (több repo kezelése), eix (gyors csomag kereső).

eix helyett én esearch-ot használok. Kevesebb infót ad ugyan, de cserébe áttekinthetőbb. Tud regex keresést (ezt nem tudom, az eix tud-e), és csak yók a tapasztalataim vele.
Ami fontos: default nem engedélyezi a post-sync adatbázisépítést, ezt neked kell utólag. Marha bonyolult, a /etc/portage/postsync.d/eupdatedb fájlnak kell futási jogot adni.

( evone | 2007. 11. 05., h – 18:44 )

a lassu fordulasi idokrol nem a gentoo tehet, hanem a lassu gepek :) nekem p4, 2.4ghzel rohadtul nem tunik lassunak, amugy gratulalok a gentoodhoz :) use flagekkel vigyazni!

( utpKabel | 2007. 11. 05., h – 19:04 )

A forditasi ido tenyleg nem veszes, kiveve ha nagyon regi geped van.

Pont ezt mondom hogy nem szoptam vele nyilván másodikra egyszer votl kisebb fennakadás a zlib useflag körül. Mindenesetre nekem ez már most áttekinthetőbb mint Debian valaha. Valahogy olyan logikus az egész. :)

---
MSI KT3 Ultra, 1GB DDR, AMD Athlon 1800+, NVIDIA GForce4 MX 440

Siettem, kimaradt egy vessző, meg a "csak a ténylegesen szükséges" kitétel. Tehát NEM a csomagokat akarom testreszabni, hanem a rendszert, és nem akarok látni benne fejlesztőeszközt (emlékezzünk meg vala a sendmail wormról...), mert semmi de semmi keresnivalója egy production környezetben.

Ha valaminek a fordítása elborul, akkor vagy ki tudom javítani (tessék érteni a C-programozáshoz), vagy nem, vagy fel bírom kalapálni az adott forrásból a cumót, vagy nem, vagy lesz valakinek hasonló problémája, vagy nem, vagy lesz legalább hasonló telepítés valahol a világban, vagy nem -- bináris csomagok esetén legalább az alapok azonosak.

NEM akarok forráskódot javítgatni, nem akarok órákat várni arra, hogy a rendszer állapota stabil (értsd aktualizált) legyen. Ráadásul ha plédául a bináris fájlok ellenörzőösszege alapján szeretném a rendszer integritását figyelni, akkor azt is totálisan sk. kell megoldani, nem pedig valamilyen csomagkezelő ad ilyen szolgáltatást. (emerging 33 of 98, kb. 5 órája megy a fordítás...)

Ja, és egy bináris disztróban van lehetőség saját csomagot fordítani egy saját, a production-tól elkülönített build-rendszeren, a Gentoo-ban a default az, hogy fordítunk...

Ja, és egy bináris disztróban van lehetőség saját csomagot fordítani egy saját, a production-tól elkülönített build-rendszeren, a Gentoo-ban a default az, hogy fordítunk...

a default az, ahogy használod. Gentoo alatt iszonyú kényelmesen meg lehet csinálni azt amit írtál. build környezetben a buildpkg feature-el forgatsz, automatikusan melléktermékként kipottyan a bináris csomag. (nem mellesleg ilyenkor a build és a production környezet binárisan egyezik, tehát tudod tesztelni hogy minden faja-e) áthuzod a bináris csomagot és tar -xjpf oszt csókolom. nem is lesz toolchain a production rendszereden. még portage sem kell legyen, semmilyen csomagkezelő.

akinek ez bonyolult, az ne használja, de amit írtál az nem igaz :)

Már megbocsáss, de a tar xjpf mióta csomagkezelés? Felrakás előtti/utáni tevékenységek, uninstall lehetőség, függőségek kezelése a production rendszeren belül, a /foo/bar/baz fájl mihez tartozik, a boo.moo.woo csomag frissítése során mit kell megőrizni (config file), mit nem... soroljak még néhány csomagkezelési feature-t, amit a tar -hogy is fogalmazzak- nem tud?

A scenario a következő. Ügyfél telephelye és gépe. van fél napom arra, hogy varászoljak neki egy telepített OS-t, mondjuk webszerverrel, php-vel, MySQL-lel, az általa adott vasra. Választhatok: vagy fogok egy bináris disztrót, vagy kreálok egy sajátot, aminek a frissítéséhez vagy kell egy másik gentoo, vagy fel kell rá pakolni egy teljes toolchain-t, és helyben forgatni. Szerinted melyik a kedvezőbb, úgy az ügyfélnek, mint nekem?

Ma reggelre pl. valami harmincegynéhány konfigfájl frissítését/átnézését kérte... Ezek közül több csak whitespace-ben tért el, azaz a régit nyugodtan felül lehetett volna vágni az újonnan érkezettel.
Eközben láttam egy oltári gányt, amitől majdnem leestem a székről...

pidfile=$(strings /usr/sbin/nscd | grep nscd.pid)

Fogalmazzunk úgy, hogy a hányinger kerülgetett ettől... Tudom, hogy átkonfigolhatom, hogy hova tegye a pidfájlt... De mi van akkor, ha a telepítési útvonalat is átkonfigurálja a felhasználó? tessék arra is felkészíteni a scriptet:

pidfile=$(strings $(which nscd) | grep nscd.pid)

:-))

Kedves zeller, remelem nem vagy olyan mint a neved.

Igenis, a Gentoo binaris csomagjai tudnak postinst folyamatokat is, csak tessen utanannezni.
Aztan a Gentoo-sok tartanak karban 1 hivatalos binhostot is a tinderbox.dev.gentoo.org webhelyen (TODO: utannanezni: PORTAGE_BINHOST).

Innentol tessek kreativnak lenni.

Nezd, ez igaz, viszont nem igenyel sok infrastrukturat. Mi kell hozza? Portage, python, tar, bzip2. Azon felul, ha valamiert leszedted a portage-t, es fel kell tenni, csak 'tar jxf /usr/portage/packages/All/${P}.tar.bz2 -C /' es utana van egy muxo portaged. Mig, ha pl. Debianon lebanyaszod a apt-t, akkor lehet szopni rendesen.

Én a következő scenario-ra gondoltam: van egy teszt / fordító környezeted, ami teljesen ugyanaz a konfig mint a production környzeted (összes /etc file, minden).

Ekkor a teszt / build környezetben ha gentoo csomagkezelővel valamit felteszel, akkor automatikusan létrejön neked egy bináris csomag. Ha bármi konfigfájt átírsz, akkor quickpkg -val tudsz belőle bináris csomagot csinálni. Ezután, a production környezetedbe hót fölösleges csomagkezelő, elég a build rendszerben összerakott környezetet áttolni. Minden frissített csomagból elég csak a binárist átteni. Nyilván direktbe sosem nyúlsz a production környezetbe, mert az mondjuk egy klaszter, száz géppel.

Így nem kell gcc a célrendszeren, mégis függőségkezelés, saját magad által ./configure-olt, fordított csomagjaid vannak, és örülsz.

De úgysem foglak meggyőzni, használj bináris disztrót...

Lehet, hogy meg fogsz győzni, illetve ha nem is te, hanem az, hogy ordenáré nagy ...ás után sincs (é. nem fordult le, csak én a székről lassan) épkézláb (pie+ssp) gcc-m máshol, úgyhogy bele fogok nyugodni, hogy 3.x-es hardened gcc-t használok, és legfeljebb ha sok időm lesz, buildelek egy debilkét gentoo alatt :-))

A leghúzósabb csomagok.

balage@aurora ~ $ genlop -lt | grep -A 1 mozilla-firefox
Thu Aug 2 12:21:56 2007 >>> www-client/mozilla-firefox-2.0.0.6
merge time: 16 minutes and 4 seconds.
--
Mon Oct 1 22:15:28 2007 >>> www-client/mozilla-firefox-2.0.0.7
merge time: 21 minutes and 2 seconds.
--
Fri Oct 19 20:43:11 2007 >>> www-client/mozilla-firefox-2.0.0.8
merge time: 40 minutes and 17 seconds.
--
Sun Nov 4 22:38:21 2007 >>> www-client/mozilla-firefox-2.0.0.9
merge time: 50 minutes and 44 seconds.

Az első két firefox ideje a ccache miatt van :)

balage@aurora ~ $ genlop -lt | grep -A 1 glibc
Sat Aug 11 12:59:15 2007 >>> sys-libs/glibc-2.5-r4
merge time: 1 hour, 1 minute and 31 seconds.
--
Wed Oct 24 00:51:20 2007 >>> sys-libs/glibc-2.6.1
merge time: 1 hour, 5 minutes and 9 seconds.

glibc sajna mindig ennyi, de legalább 2.4-től már nem kell (lehet) 2x lefordítani az nptl miatt :)

balage@aurora ~ $ genlop -lt | grep -A 1 wine
Wed Aug 22 02:07:12 2007 >>> app-emulation/wine-0.9.43
merge time: 20 minutes and 46 seconds.
--
Mon Oct 15 22:02:54 2007 >>> app-emulation/wine-0.9.47
merge time: 19 minutes and 38 seconds.

Opcionális. Nem mindenki használ wine-t.

balage@aurora ~ $ genlop -lt | grep -A 1 gimp
Fri Jul 27 22:07:25 2007 >>> media-gfx/gimp-2.3.19
merge time: 14 minutes and 30 seconds.
--
Sun Aug 19 15:44:25 2007 >>> media-gfx/gimp-2.4.0_rc1
merge time: 15 minutes and 51 seconds.
--
Sun Sep 9 21:35:05 2007 >>> media-gfx/gimp-2.4.0_rc2
merge time: 14 minutes and 3 seconds.
--
Wed Sep 26 10:55:08 2007 >>> media-gfx/gimp-2.4.0_rc3
merge time: 12 minutes and 56 seconds.
--
Wed Oct 24 21:01:58 2007 >>> media-gfx/gimp-2.4.0
merge time: 13 minutes and 41 seconds.
--
Thu Oct 25 22:48:07 2007 >>> media-gfx/gimp-2.4.0
merge time: 16 minutes and 16 seconds.
--
Sun Nov 4 22:52:57 2007 >>> media-gfx/gimp-2.4.1
merge time: 14 minutes and 36 seconds.

A 15-20 perc nem sok egy programra. A gimp-et csak azért írtam be, mert arról van a legtöbb statisztikám.
A vas: TurionX2 64 - 1600Mhz / 1GB RAM
--
http://kac.duf.hu/~balage/blog

Nos nekem is eltartott anno 1-2 napig mire rájöttem, hogy nem árt felrakni hozzá magát a ccache-t :D
# emerge -av ccache
+ nemárt rendesen beállítani a globális változókat, mert a make.conf változói csak a fordítás idejére vonatkoznak.
Az alábbi komment sokat segíthet: ;)

balage@aurora ~ $ cat /etc/env.d/99locale
CCACHE_DIR="/mnt/x-meghajto/GENTOO/ccache"
LANG="hu_HU.UTF-8"
LC_ALL="hu_HU.UTF-8"
PATH="${PATH}:/usr/local/bin:"

--
http://kac.duf.hu/~balage/blog

Nálam ennyi + az emerge -av ccache:

balage@aurora ~ $ cat /etc/make.conf | grep -i ccache
FEATURES="buildpkg ccache parallel-fetch sandbox strict userfetch"
CCACHE_DIR="/mnt/x-meghajto/GENTOO/ccache"
CCACHE_SIZE="2000M"

Valahol talán a path-t is állítani kell, itt tuti leírják mit/merre/hogyan? ccache - gentoo wiki
--
http://kac.duf.hu/~balage/blog

Ege megen én voltam a hülye.Igy már van cache-elve... De akkor minek a /root beli ccache könyvtár? Egy csomó dolgot tanultam de még sokszor vannak sötét foltok na ... :)
engem bekavart a wikin ez:

Note: I could not get ccache to work properly until I created a symlink, it seems to be getting confused by the existence of two separate directory locations.

mv /root/.ccache /root/snafu.ccache
ln -s /var/tmp/ccache /root/.ccache

After that everything worked. I have been using it for awhile now (including emerge world) with no problems. (codeslinger.comspalot)

sorry fáradt vagyok. Köszönöm a segítséget :)

---
MSI KT3 Ultra, 1GB DDR, AMD Athlon 1800++, NVIDIA GForce4 MX 440