nih - csomagkezelő a pkgsrc-hez

Címkék

Aleksey Cheusov a napokban jelentette be a pkgsrc-users levelezési listán, hogy egy új, a pkgsrc-hez használható csomagkezelőn dolgozik. A neve "nih", amely a "not invented here" rövidítése. A néhány hete fejlesztett nih távoli céljai közt szerepel, hogy mind bináris, mind forrás-alapú frissítési képességekkel bírjon (jelenleg csak a bináris frissítést implementálta a fejlesztő). A bejelentés szerint a nih nagyon hasonlít a Linux világban ismert zypper, apt és yum csomagkezelőkhöz.

Jellemzői:

  • perl-5.10->5.12 or similar huge updates may be done fully automatically without interaction with user
  • first - questions (prompts), second - actions
  • nih starts to delete/add packages only if it is absolutely sure that the whole system at the end of update will be in a consistent state (DEPENDS, CONFLICTS, PROVIDES/REQUIRES are analysed). It should not stop anywhere in the middle and leave system in inconsistent state unless I missed something.
  • during update conflicts and missed dependencies (if any) may be resolved manually step by step if they cannot be resolve automatically for any reason
  • remarkable search capabilities
  • flexibility, nih is written in shell (based on wip/pkg_summary-utils)
  • nih downloads all binaries before starting the update
  • see the manual page for the rest

A csomag verziószáma (0.0) jelzi, hogy a csomag még nem stabil állapotú, aktív fejlesztés alatt áll, de ettől függetlenül már lehet vele játszani és biztonságosnak tekinthető (csomagtelepítés vagy eltávolítás előtt szól).

A bejelentés elolvasható itt.

Hozzászólások

kicsit meglepőnek tartom hogy shell-ben írja. azt értem hogy a userspace tool-ok használatával gyors, de ha hosszú távon bármit maga implementál, akkor a sebesség azért megkérdőjelezhető.

erről a SAT dologról tudnál mondani valamit? Eleve a SAT meg NP eldöntési problémák körébe tarozik, az meg, hogy adott csomagnak mik a függőségei, az nem eldöntési probléma. Mindenesetre nem látom mi lenne itt, ami nem triviálisan polinomiális. Vö. pl. Dj Xtra: "Let go rythm".

Amúgy meg mi az h. "optimálisan"? Mivel a függőség kérdése matematikailag jól definiált, e jelző az eredményre nem vonatkoztathatól, nincs olyan h optimális v. nem optimális eredmény, hanem csak az eredmény van (szemben pl. a weben való kereséssel, ahol heurisztikus eredmények vannak). Így tehát az optimalitást a számításigény szempontjából tudom csak értelmezni. Viszont amit te mondasz meg azt sugallja, mintha lehetne beszélni szuboptimális, de olcsó megoldásról :)

http://scholar.google.hu/scholar?start=10&q=sat+package+dependencies&hl…

Nem egy egyszerű DAG-ként fogalmazzák meg ezt a problémát, vannak csomagok meg azoknak felsorolva a függőségei, mert akkor igazad lenne. Hanem többféle viszonyt is figyelembe vesznek:
A megköveteli B-t
A konfliktusban van B-vel
A kiváltja B-t

Így kell megkeresni azokat a csomagokat amik az elvárt funkciókat kielégítik, és ez már korántsem olyan egyszerű. (Ezek a szabályok különösen megszaporodnak amikor minden program és library több verzióban is elérhető a repoban.)

ha csak példának veszem az apt tudását, mint pl. részletes infó generálása csomagokról, úgymint tartalmazott fájlok listázása, függőségi lista le és fel irányban (redepends), telepített összetevők listázása és egyéb ami most nem jut eszembe, akkor valami azt érezteti velem így elsőre, hogy akkor is sokat számíthat maga a csomagkezelő teljesítménye, főleg napi sűrű használat alatt, amikor az 1 másodperc már lélektani határ bizonyos parancsok futásának kivárásához, amelyet sokszor futtatok (és ennek nagy része nem csomag telepítés).

esetleg ha minden időidényes feladatra külső C-s program fut?

Ezen feladatok egy jelentos resze BSD-n - emlekeim szerint - egy egyszeru cat vagy grep. Teljesen felesleges lenne azt tovabb optimalizalni.

Javasolnam, hogy mielott barki sir amiatt, hogy shellben van irva, eloszor nezze meg, hogy az tenyleg gond-e, es tenyleg jelentosen gyorsabb lenne-e, ha mondjuk C-ben lenne irva. (Tippre: nem; foleg akkor ha megfeleloen van felepitve az 'adatbazis')

--
|8]

Csak igen távolról emlékeztet rá, de a FreeBSD ports-ban levő csomagkezelő, a portmaster is kutya-közönséges shell-script. És kategóriákkal gyorsabb(nak tűnik), mint a portupgrade, amit nálam kiváltott. (Ami még mindig nem natív gépi kód, mert Ruby a lelkem.) És noha van egyetlen pontja a frissítéseknek, ahol kicsit lassúnak érzem, de messze nem az a lassú/időigényes, hanem a fordítás (néha a letöltés, bár azt nagyon szépen csinálja a háttérben).

Én erre csak ennyit tudok mondani, nekem ez vállalható.


$ time pkg_info -a > /dev/null
        4,03 real         0,49 user         0,24 sys
$ pkg_info | wc -l
     760
$ time pkg_info > /dev/null
        0,69 real         0,49 user         0,13 sys
$ 

Szóval 700 fölötti csomagra 4 másodperc szerintem elviselhető. Ha nincs benne devnull átirányítás, akkor viszont nem a csomagkezelőket, hanem kb a konzol alrendszer áteresztőképességét teszteled. Szerintem. (És azt már figyelembe se vettem, hogy tudtommal az rpm-nél is, a dpkg-nél is van mögötte valódi DB, míg a FreeBSD csomagoknál ez a /var/db/pkg könyvtárstruktúra.) De még egyszer mondom, ez csak egy vélemény.

Nincs mögötte db ugyanúgy egy könyvtár struktúra a /var/lib/dpkg alatt.

Amúgy:

time dpkg -l

real 0m0.536s
user 0m0.120s
sys 0m0.028s

time dpkg -l >/dev/null

real 0m0.142s
user 0m0.128s
sys 0m0.012s

dpkg -l | wc -l
1936

A FreeBSD csomagkezelőjével nincs bajom. A keservesen lassú az az OpenSolaris (most ill majd a Solaris 11) pkg nevű új csomagkezelője ami egy apt-get update jellegű parancsot percekig futtatott nekem, ill a keresés is keservesen lassú volt.
Ez egyébként python alapú.

Régebben a yum-al is voltak ilyen jellegű bajok, de az most már kellően gyors.

Egyébként az ilyen előre kiszámított, lekérdezésekkor használt cache nyilván nagyon jó szolgálatot tesz a teljesítmények. Csak ugye felmerülnek (mint minden adatbázisnál) a konzisztencia kérdések:

- Konzisztens marad-e cache a mindennapi használatban
- Gyorsan és megbízhatóan észlelhető-e az esetleges inkonzisztencia
- Ki lehet-e javítani vagy újra lehet-e építeni a cache-t akár nulláról és milyen gyorsan
- És végül a felhasználói élmény: mindezek a lépések mennyire automatikusak?

Hmm tényleg nem tudtam.

De elvben? újra lehet építeni ha megsérül a /var/lib/dpkg/available' és a '/var/lib/dpkg/info/*.list file-k alapján.

Na ennek a teljesítményével lehetne akkor összevetni a pkg_info-t.

Egyébként a /var/backups alá default telepítés esetén naponta menti a debian.

Hahó!

A shell viszont szinte minden, a pkgsrc által támogatott rendszeren (http://www.netbsd.org/docs/software/packages.html#platforms) létezik (elérhető), így elég egy megoldást elkészíteni, s az az összes rendszeren kipróbálható lesz.

A jelzett változat egyébként még fejlesztési változatban készül (,,wip: work in progress''), ezért a fő szempont nem a gyorsaság, hanem a jó működés.

Optimalizálni (gyorsítani) akár később is lehet a már jól működő változatot. (Brian Kernighan: "First make it run, then make it run fast". http://wiki.osdev.org/History)

G.
============================================
"Share what you know. Learn what you don't."