- 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.
- A hozzászóláshoz be kell jelentkezni
- 3475 megtekintés
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ő.
- A hozzászóláshoz be kell jelentkezni
Annak idején sokat vitáztak ugyanez miatt a Gentoo csomagkezelője miatt, mivel a forrásfájlok bash scriptek, a csomagkezelőt meg python-ban írták. Ettől függetlenül nem mondanám használhatatlanul lassúnak. :)
Ha jól tudom az Archos AUR is valami hasonló "böszmeség".
- A hozzászóláshoz be kell jelentkezni
A telepites soran nem a csomagkezelo lesz a teljesitmeny szuk keresztmetszete, igy ha asm-ben irna, szerintem akkor sem lenne az ossz futasido jelentosen gyorsabb.
Valamennyivel persze, de nem annyival hogy megerje ezert felaldozni a shellben irattatas elonyeit.
--
|8]
- A hozzászóláshoz be kell jelentkezni
A csomagkezelő egyik fő feladata a függőségek helyes kezelése: na ez rendkívül számításigényes lehet - ha optimálisan akarják megcsinálni.
/Igazából SAT problémaként fogalmazzák meg mostanában a divatos csomagkezelők ami ugye NP-teljes./
- A hozzászóláshoz be kell jelentkezni
Igen, de az meg mindig elenyeszo ido a letoltes + telepiteshez kepest (plane ha meg forgatas is van utkozben). Nem az a szuk keresztmetszet.
--
|8]
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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]
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Nem tudom, de egy "pkg_info -a" parancs több másodperc alatt fut le több száz telepített csomag esetében, míg ugyanez az idő "dpkg -l" v. "rpm -qa" esetében nem mérhető. Nem mintha számítana, de mégis.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
dpkg-nal sincs valodi db mogotte (legalabbis legutobb amikor neztem nem volt), aptnal van egy cache.
--
|8]
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
op@scylla ~> strace dpkg -l | & grep open | grep status
open("/var/lib/dpkg/status", O_RDONLY|O_LARGEFILE) = 3
___
info
- A hozzászóláshoz be kell jelentkezni
scylla:/home/op# mv /var/lib/dpkg/status /var/lib/dpkg/status.asd
scylla:/home/op# dpkg -l
dpkg-query: failed to open package info file `/var/lib/dpkg/status' for reading: No such file or directory
___
info
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
igen, es ez most hogy jon a dpkg-hoz?
mivel a dpkg a debian alapu rendszerek alapja, igy igen, automatikus, nem veletlen nem tudta feljebb sem valaki, hogy egy db-bol dolgozik, es nem konyvtarbol
___
info
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Amennyiben a /var/lib/dpkg/status "db", akkor igen, db-bol dolgozik.
A magam reszerol en nem neveznem db-nek. Erdemes megnezni, hogy epul fel.
--
|8]
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
s
- A hozzászóláshoz be kell jelentkezni