Új Gentoo kiadási stratégia

Gentoo

Az elmúlt egy évben több probléma is akadt az új Gentoo kiadások körül, ezért úgy döntöttek, hogy változtatnak az eddigi gyakorlaton. Ezután:

  • Hetente új minimal LiveCD és stages. Ezek automatikusan készülnek.
  • Évente egy teljes kiadás nagy LiveCD-vel, grafikus telepítővel, stb.

Ez a stratégia jól illeszkedik a Gentoo filozófiájához. A csomagok eddig is a kiadásoktól függetlenül, folyamatosan frissültek. Erre azért volt szükség, mert nincs elég ember a kiadások elkészítéséhez, és emiatt több csúszás volt az elmúlt évben. Ha bárkinek kedve támad segíteni ebben a folyamatban, a releng csapat várja az új jelentkezőket. Ezen okok miatt a Gentoo 2008.1 kiadás elmarad.

( hrgy84 | 2008. 09. 24., sze – 18:19 )

Ha mindig friss install CD meg stages lesz, az jo, mert nem kell 0-rol kezdeni a frissitest mindig (par honap alatt a komplett alaprendszer tud frissulni).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

kerdes, hogy automatikus alatt pontosan mit ertenek. ha ugy automatikus ahogy pl a -git patchek a kernel eseteben (tehat teljesen automatikus, nincs kezi ellenorzes) akkor ez tul sokat nem er, 1-1 csomag frissitese agyonvaghatja az egeszet.

(tobbek kozott ez az oka annak, hogy a frugalware eseten is legalabb 2havonta van egy pre vagy rc kiadas; ilyenkor mindig helyrepofozzuk az installert ha van vele valami gond - a legtobbszor van valami apro problema.)

Szerintem ugy automatikus mint egy nightly build. Szoval fogjak az aktualis allapotot es buildelnek belole egyet. Azert itt nem kell elfelejteni, hogy stable agbol buildel. Szoval a csomagok nagy resze mar igen jol ki van tesztelve. Plusz minimal LiveCD eseteben nincs installer, szoval azzal nem lehet baj. Ugy is megoldhato, hogy csutortokon buildelnek, egy valamenyi teszteles utan penteken kikerul.

Szerintem meg ok se tudjak pontosan, hogy mi lesz :)

Mindig a stable agbol csinljak a stageket.

Most csinaltam en is catalyst el stageket. _Az nagyon szepen lement_.
De a livecd kreallassal most vannak gondok.
- cirkulalis dependenciak -> kezzel beleavetkozni es az xorg-server minimalis falgekkel forgatni egyszer.
- currus driver alapbol nincs benne (qemu), ha bele teszem maximalis pixel frekvencia valamiert 0 lesz, atalitani nem engedi, es nem talal valid modot, majd meg jatszok vele.
szerk: 1.2.1 currus megy.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

En nem szokom a cirrus drivert becezni :D

Amugy en csak a mini install cd-re gondoltam, gondolom ok is hasonlo okok mian vallaltak csak az install lemez buildeleset, a livecd ennel picit (oke, sokkal) bonyolultabb czucc.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( Yorirou | 2008. 09. 24., sze – 19:37 )

És mi lenne, ha végre lenne KDE team, ami megcsinálja a KDE4 ebuildeket?

Andi, really. Take it from me. If I tell you something, I'm usually right.

( fdavid | 2008. 09. 24., sze – 22:56 )

Ez gyakorlatilag annak a jele, hogy mar semmilyen kiaadasi ciklus sem tarthato a jelenlegi eroforrasokkal. Kivancsi leszek, hogy az eves buildet majd milyen otlettel fogjak lefujni. Eltuntek a fejlesztok, es meg most az automatara allas folyik mielott az utolso leoltja a villanyt.

Elnezest ha negativ voltam, de 2003 ota Gentoo felhasznalo vagyok (az otthoni gepemen kizarolagos rendszer az 5,5 eves folyamatosan frissitett eredeti installacio), de 2 eve tarto folyamatos lerohadast ilyen ugymond "strategiavaltassal" nem lehet kezelni. Mindig is nagyon szerettem ezt a rendszert es tovabbra sincs olyen masik disztribucio, ami ezt nyujtana, amit a Gentoo. Ezert sosem akartam valtani, de egy eve mar komolyan gondolkodom rajta, hogy mit tegyek, ha megszunik. Ez szerintem egy ujabb egyertelmu jele annak, hogy ez elobb-utobb bekovetkezik.

Hát jó nagy űr maradna utána. Az exherbo az sehol sincsen, a többi meg kicsi.

Valaki, aki járatos a belügyekben, tudna mesélni, hogy tulajdonképpen mi is történt? Mert azt olvastam, hogy a KDE teamnek a council tett be (?), de honnan indult a sztori?

Andi, really. Take it from me. If I tell you something, I'm usually right.

inho drobbins távozása óta nincs igazi vezetője a gentoonak. ugyanakkor nem látom olyan sötétnek a jövőt. a gentoo total bazaar disztribúcióvá vált mára. ennek szokatlan és nem túl szerencsés következménye az épkézláb vezetés teljes hiánya. de a gentoo mégis létezik, és a computer mögött ülve ma is használhatóak a legújabb gnu/linuxra írt programok, mint a teljesen más rendszerben üzemelő ubuntun. ennek az egyik oka, hogy jóval kevesebb emberi erőforrásra van szükség egy .ebuild file elkészítéséhez, mint egy .deb csomagéhoz.
a legjobb webes gentoos oldalakat egyébként sem gentoo.org domainen érdemes keresni mostanában. csomagkeresésre ott a független http://www.gentoo-portage.com, vagy http://www.larrythecow.org/ oldalai, ahol a gentoo hírek is találhatóak. a http://www.gentoo-wiki.com/ címen található howto gyűjtemény, lassan a legnagyobb linuxos gyakorlati doksivá növi ki magát, és már nem csak gentoosok használják. ez is független a hivatalos gentoo projecttől.
igazából csak egy kényelmesen kezelhető független repository kezelő rendszerre lenne szükség. attól kezdve még tovább csökkenhetne a központi, és egyébként is rosszul működő gentoo management jelentősége.

Azert mert ha szuksegem van egy uj csomagra akkor eleg letoltenem egy ebuild filet (mondjuk a bugzillabol) es betennen az overlay-be. Ha a keszito nem gondolt amd64-be beleteszek egy keywordot az ebuildba es kesz. Gentoo-nal ha kijon egy uj verzio sokszor eleg csak atnevezni az ebuild-et es mar mukodik is!

Ugyanez deb eseteben valahol kell neten tarhely ahol eltarolod a binaris csomagot (bugzilla nem jo), ami csak egy bizonyos debian verziohoz jo a kulonbozo libek miatt. Ha a te architektura, disztro verziodra nem froditottak akkor igy jartal. Ugyan debian eseteben is lehet lokalisan deb-et kesziteni, de ahhoz fel kell epiteni egy teljes build kornyezetet, ami Gentoo-nal alapbol rendelkezesre all (kulonbozo dev csomagok, deb buildelo cuccok...). Emlekszem anno Debian alatt egy kernel leforditasahoz is fel kellett tegyek valami 10 plusz csomagot.

"Azert mert ha szuksegem van egy uj csomagra akkor eleg letoltenem egy ebuild filet (mondjuk a bugzillabol)"

Az hogy bugzillából kell beszerezni ebuild filet már eleve humoros, de ezzel most ne foglalkozzunk.

Az eredeti kijelentés nem az volt, hogy 'jóval kevesebb hálózati forgalomra van szükség egy .ebuild file _letöltéséhez_', ez sok esetben igaz is lenne, hanem az, hogy 'jóval kevesebb emberi erőforrásra van szükség egy .ebuild file _elkészítéséhez_'.

"Ha a keszito nem gondolt amd64-be beleteszek egy keywordot az ebuildba es kesz."

A .deb esetén pedig a control filet módosítod...

Persze már az eredeti kijelentés is sántít, hiszen a fordításért és telepítésért felelős bash scriptet (.ebuild) hasonlít egy már lefordított és teljesen kész csomaghoz (.deb). Tehát Apples and Oranges... Mivel az emberi erőforrásról volt szó és a forrás lefordítását egyik esetben sem ember végzi, ezért ezen most nagyvonalúan továbbléphetünk, de nyilván a korrekt összehasonlítás az .ebuild mellett a .deb-hez tartozó control fileok lennének. ;)

"Ugyanez deb eseteben valahol kell neten tarhely ahol eltarolod a binaris csomagot"

A .deb csomag elkészítésének semmi köze a .deb csomag elhelyezéséhez vagy telepítéséhez. Márpedig az eredeti kijelentésben csak az elkészítésről volt szó és én arra reagáltam.

"ahhoz fel kell epiteni egy teljes build kornyezetet, ami Gentoo-nal alapbol rendelkezesre all"

Ennek megint semmi köze az eredeti kijelentéshez. Persze azzal is lehetne vitatkozni, hogy mit jelent az 'alapból rendelkezésre áll', hisz Gentoo alatt is egy külön "csomag" a portage, a python, a sandbox és a többi, csak a stage3-ban, amiből valószínűleg kiindulsz, abban telepítve vannak.

Emberi erőforrás oldalról pedig nem "jóval kevesebb" az .ebuild file elkészítése (pláne ha from scratch kell valamihez megírni), mert a .deb elkészítésének legnagyobb részét is a gép végzi, hisz a ugyanúgy a legtöbb minden automatizálva van, a leíró fileok között, amelyek a dependenciát, architektúrát és a többit kezelik pedig nincs akkora oltári nagy különbség.

Ne keverjük azért.

1. Nem bugzillából "kell beszerezni" az ebuild-eket. Onnan max a legújabb verziót töltöd le, ha nagyon akarsz egy új csomagot, de még nincs benne a portage-ben, és valaki már csinált belőle saját ebuild-et.

2. Az ebuild nem bash script, csak egyszerű szövegfájl.

Amúgy az egészről az a véleményem, hogy egyszerűen csak más a csomagkezelés, valamint fölösleges vitatkozni azon, hogy melyik gyorsabb, melyik kíván kevesebb erőforrást.

Szerk: typo-k eltüntetve

"1. Nem bugzillából "kell beszerezni" az ebuild-eket."

Nekem nem kell megmagyarázni. Aki bugzillából töltöget és használ ész nélkül ebuildeket, az ne csodálkozzon, ha egyszer csak megtörik a rendszerét.

"2. Az ebuild nem bash script, csak egyszerű szövegfájl."

Ennek nézzél még kicsit azért utána... ;)

a bugzilla a gentoo esetében kicsit mást jelent, mint sok project esetében. sok új, sőt nem is annyira új .ebuild található ott, amikre valahogy nem marad ideje az official gentoo staffnak, hogy vegye a fáradságot és betegye a portageba.
egyébként pedig nincs velük probléma, nem bugosak.

Ha nagyon paranoias vagy atnezed mielott futtatnad. Egy 20 soros bash script atnezese nem olyan nagy feladat.

Viszont ha igy nezzuk egy 3rd party repot nem hasznalhatsz, mert ki tudja mit tesznek fel. Binaris disztroknal pedig teljesen zsakbamacska amit letoltesz. Sot tovabbmegyek most volt hir, hogy a Fedora szervereit megtortek, meg az eredeti repok se biztonsagosak. Szoval csak olyan kodban bizhatsz amit te irtal. De ha nem vagy egy security expert akkor siman vethetsz hibakat amit masok kihasznalnak...

Hat nem tudom. Eleg regota keszitek es managelek (khmm... szoval idonkent rafrissitek) csomagokat Gentoo-ra. Mostanaba neztem meg, hogy lehet *.deb csomagokat kesziteni. Hat ize.

1) Aki a control fajlok szintaxisat kitalalta, szerintem az eletben nem gyartott meg ilyent, nehezkes, bonyolult, meg elsore nem is trivialis. Rendes step-by-step howto (valos csomaggal) sehol, ami van, abbol mindent lehet, csak epp tanulni nem.
2) Eleve a debian hozzaallasa nem tetszik, hogy minden (amugy 1 darab csomagot) 3-5 csomagra szed szet (bin, lib, doc, dev - es meg akkor a jobbik esetet mondtam). Ha valami 1 darab valami az legyen 1 darab csomag, sokkal konnyebb menedzselni (Xorg termeszetesen excluded, azzal mas bajok vannak, de ez nem az a tema).
3) Az mar csak hab a tortan, hogy a rules fajl meg abszolut nincs ledokumentalva, milyen built-in valtozok erhetok el, mit lehet megtenni es mit nem, van-e valamilyen kontroll afelett, hogy ne barmolja szet egy rosszul megirt csomag az elo rendszert (lasd meg: sandbox). Oke, erre lehet valaszokat talalni, meg azt is tudom, hogy a fejleszto halala a dokumentalas, de ha mar professzionalisnak akarjuk hivni a rendszerunket, igencsak kene tamogatni a csomagkeszitoket is - azokat is, akiknek nincs @debian.org e-mail cimuk.

Bennem amugy az egesz csomagkezelesi rendszer folyamatosan azt az erzetet kelti, hogy valaki valamikor osszedobott valamit, es most azt probaljak meg kikalapalni, hogy menjen. Neha sikerul, neha nem.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Én annak idején azt szerettem az egyik legjobban a Gentoo-ban, hogy sok más disztribúcióval ellentétben, nem kell repositorykra vadászgatni, hanem minden csomag alapból megvan a fő tárolóban. Nekem kifejezetten nem tetszik az, hogy overlayekre kezdik bontogatni. Minek? Ha valakinek van egy népszerű overlay-e, és az userek azt mondják, hogy _működik_, akkor miért nem olvasztják be a fő portage fába? Erre a hivatalos indok az, hogy "mert nem olyan jó minőségűek az ebuildek". Naés? Tessék hard maskedre rakni, aztán ha működik, akkor unstable, és ha kicicomázták az ebuildet, akkor stable.

A Gentoo managementet meg ki kellene vágni a francba, és kinevezni egy embert, akinek van ideje rá, és elég határozott ahhoz, hogy vezessen egy projektet.

Andi, really. Take it from me. If I tell you something, I'm usually right.

ezért kellenének repok a gentooba. persze ezek más célt szolgálnának, mint a debian/ubuntu esetében. így egy külsős csapat ha "eléggé jó minőségűnek" tartja a saját munkáját, akkor a hivatalos gentoo teammel való vitatkozás helyett csak kitennék a repojukba, és a userek dönthetnek arról, hogy valóban "eléggé jó minőségű" e.

Az az igazsag, hogy az keves, hogy X user azt mondja, hogy megy, mert a kevesbe popularis platformokra (arm*, mips*, ppc*, sparc) nincs tul sok teszter. Viszont jo lenne, ha a portage fa nem csak x86/amd64 csomagokkal lenne tele, mert akkor a tobbi platform tulaja fog sikitozni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.