Bétába fordult a pkgng fejlesztése

FreeBSD

A pkgng egy következő generációs csomagkezelő a FreeBSD-hez. A pkgng nem ports kezelő eszköz (fogalma sincs arról, hogy hogyan készül el (fordul le) egy port), nem portupgrade/portmaster helyettesítő. A pkgng a pkg_* segédprogramok helyettesítője lehet a jövőben. Egy eszköz a telepített csomagok lekérdezéséhez, kezeléséhez, bináris csomagok kezeléséhez, használható távoli tárolókból való csomagtelepítéshez, csomagfrissítéshez.

Baptiste Daroussin (bapt@) bejelentette, hogy a pkgng fejlesztése odáig jutott, hogy az eszköz béta állapotba került. Miért van szükség a pkgng-re? Baptiste szerint azért, mert a pkg_* programok elavultak, nehéz őket karbantartani és számos funkció hiányzik belőlük. A régi, elavult eszközök megléte mellett nehéz fejleszteni a ports infrastruktúrát, így a csere kívánatos.

A pkgng-ről részletesen itt.

( hrgy84 | 2012. 01. 31., k – 22:52 )

Jopofa cucc. Vegre egyszerusodik a BSD-k kezelese is, ez jo...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( uid_18247 | 2012. 01. 31., k – 23:59 )

akinek nincs kedve elolvasni a bejelentést:

"The plan is to have pkgng 1.0 ready and rock solid for 10.0-RELEASE and 9.1-RELEASE."

(ez egy rejtett subscribe)

-----------
A barátnőm azt mondta, néha próbáljam meg a világot az ő szemével nézni. Úgyhogy kinéztem a konyhaablakon.

Annyira nyugtalanított a dolog, hogy biztos-ami-biztos alapon azért megnéztem közben, és legalább kissé jobban képbe kerültem. Ami engem illet, nem akkora nagy durranás. Ugyanis szerintem ami valóban szükséges és FreeBSD alatt az alaprendszerből hiányzik, az a bináris csomagok upgrade-je, de mióta van portmaster -PP, azóta a portmaster 100 KB-os szkripje nekem nem fáj az alaprendszerben levőkön kívül. De azért csak csinálják nyugodtan.

Nincs az 20+ :-) . Megnéztem a /usr/share/misc/bsd-family-tree fájlt. Emlékeim szerint 2.0.5 FreeBSD előtt egy kicsivel kezdtem FreeBSD-zni, annak kiadási dátuma 1995-06-10. Ez még a nagykorúsághoz se elegendő. Persze ha hozzávesszük, hogy néhány évvel korábban már használtam 386BSD-t, amiből én a 0.1-gyel barátkoztam, aminek kiadási dátuma 1992-07-28, akkor azért legalább közelebb kerülünk a 20-hoz ;-) Az is igaz, 4.3BSD Net/2 (1991-06-28) anyag volt már korábban a kezeim között, de ott csak a kóddal szemezgettem, használni nem használtam.

Úgy tudom, OpenBSD-n is van csomagfrissítés.

Mondjuk azt nem is értettem soha, hogy ezt épp miért nem sikerült megportolni a különböző BSD-k között. Mindegy, még 2 év, és lesz ebből valami. Mondjuk hogy miért nem kiegészítik a meglevő készletet egy pkg_upgrade / pkg_update vagy hasonló paranccsal, arra nekem kevés oknak tűnik az, hogy mondjuk a +REQUIRED_BY az egy hack. Úgy gondolom, hogy akkor is hack, ha ez egy SQLite adatbázisban lesz tárolva. Viszont ez azt is jelenti, hogy az SQLite valamilyen verziójának oprendszerbe importálása is be fog következni, nem?

a) Szerintem az, hogy egy felhasznált libet nem függőségként kezelünk, hanem fogjuk az X verzióját és beépítjük a saját szoftverünkbe, hosszú távon pont hogy nem jó. Én is tudom, hogy ezzel a verzióval el lehet kerülni a kezdetben használt X.Y és a későbbiekben megjelenő X+m.Y+n verziók közötti (esetleg rejtett) inkompatibilitásból adódó problémákat, de magukra vállaljuk egy (amúgy tőlünk független) fejlesztés később kiderülő hibáinak backportolási problémáit.

b) Ha pedig nem kerül bele a pkgng az alaprendszerbe, ellenben (ahogy lejjebb írod) - majdan teljesen leváltja azt, ebből nekem az jön le, hogy a jövőre nézve két lehetőség van:

- a FreeBSD (ellentétben a trendekkel) - szépen lassan kidobja az alaprendszerből a bináris csomagkezelést, és már a csomagkezelőt is csomagból kéne föltenni, nade mivel??? - ez szerintem katasztrófa lenne.

- megmaradna a régi pkg_*, és lenne *mellette* egy, az alaprendszernek nem részét képező alternatíva; amilyen jelenleg pl. a portupgrade (a maga böszme Ruby-függésével) vagy a portmaster (a maga 100k-nyi szkriptségével). Én egyébként ez utóbbit tettem volna bele a rendszerbe (pont a miatt, hogy rohadtul nincs semmilyen függése, szépen megy a gyári sh-val / bash-sal / (pd)ksh(93)-mal.)

Meg persze van az, hogy nem értem fenti és lenti hozzászólásod mögött a tartalmat - ez tűnik reálisnak.

Ne engem kérdezz erről, hogy miért ilyen módon vették bele az SQLite-ot :) Gyanítom, Baptiste szerette volna az SQL adta lehetőségeket alkalmazni a csomagokkal kapcsolatos műveletek kényelmes implementálásában, az SQLite pedig méretét és egyszerűségét tekintve éppen megfelelőnek találtatott. Hogy ez milyen szoftverfejlesztési problémákat hoz magával, nos, ez majd csak az idő tudja megmondani szerintem.

A helyes válasz talán az lehetne, hogy a FreeBSD Projekt továbbra is foglalkozik a bináris csomagokkal, azonban az alaprendszer különválik tőle ütemezésében, tehát elegendő a kiadásokban az alaprendszert a bináris csomagok nélkül vagy azok egy adott kiadásával (gondoljunk itt például a NetBSD negyedéves pkgsrc snapshotjaira) szállítani.

A "tyúk vagy a tojás" problémáját pedig a pkgng bootstrap igyekszik feloldani, vagyis igen, csomagból (esetleg portból...) kell feltelepíteni a csomagkezelőt :-) Viszont ha jól emlékszem, ez a pkgsrc esetében sem akkor probléma.

Hát nem tudom, de nekem az volt az érzésem, hogy ennél azért kicsit többről szól a pkgng projekt. (Tegyük hozzá, én azért 5 percnél többet foglalkoztam vele, lévén, hogy kb. tavaly karácsony óta használom mind a két oldaláról.)

A srácoknak első körben leginkább az a céljuk, hogy egy zökkenőmentes átállást valósítsanak meg a korábbi bináris csomagkezelő megoldásról -- amelyből következik, hogy először valóban nem lesz több, mint a pkg_* programok leváltása. De mivel a háttérben ennél azért valamivel több történt, később, miután megszabadultak a pkg_* programoktól (és azok korlátaitól), elkezdődhetnek az érdemi fejlesztések, pl. a bináris csomagfrissítés támogatása.

Egyébként megsúgom: a pkgng és a bináris csomagkezelés többet már nem lesz az alaprendszer része, a fejlesztők a jövőben sokkal rugalmasabbnak látják a kettőt külön kezelni.