Názor k článku Flatpak, Snap, Modularity: počátek konce éry balíčkovacích systémů? od ja. - Backend pre storage flatpakovych aplikacii sa nazyva OSTree....

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 11. 2018 16:36

    ja. (neregistrovaný)

    Backend pre storage flatpakovych aplikacii sa nazyva OSTree. Je velmi podobny git repository v tom, ze kazdy subor je v content-addresable storage (t.j. subor je nazvany svojim hashom). Na rozdiel od gitu, a) checkout nie je kopia, ale hardlink do c-a storage a b) je mozne mat vycheckovanych niekolko rozlicnych branches naraz (v rozlicnych adresaroch, samozrejme).

    Kazda aplikacia je samostany branch. Kazdy runtime je tiez samostatny branch. Kazdy major release, ktory moze menit ABI, je tiez samostatny branch (major verzia je sucastou nazvu, t.j. org.gnome.Plat­form/3.28 je iny branch ako org.gnome.Plat­form/3.30). Instalacia spociva v tom, ze sa z prislusneho remote (ten isty koncept ako pri git) potiahnu vsetky objekty, ktore su pre dany branch potrebne a vycheckuju sa do adresara. Pokial nejaka ina aplikacia alebo runtime pouziva ten isty objekt ako nejaka existujuca aplikacia alebo framework, tak sa logicky stahovat nemusi, pretoze uz v repository je. Pokial je nejaka aplikacia updatuje, tak sa urobi ekvivalent git pull a novy checkout; stary a novy mozu byt paralelne, ked sa stary prestane pouzivat, tak sa odstrani, dalsi start je uz do noveho. Je mozne urobit ekivalent autoremove, a z repozitory odstranit vsetky branche, ktore nie su uz potrebne (frameworky, ktore uz ziadna aplikacia nepouziva).

    Pri instalacii sa ziadne dependency nikam nezapisuju; kazdy balicek ma manifest. Aplikacia moze pouzivat najviac jeden framework; nie je vsak problem vytvorit novy framework, ktory "zdedi" subory existujuceho (GNOME aj KDE frameworky dedia subory z org.freedesktop­.Platform, ktory je barebone) a tym padom su stale na disku iba raz, aj mmapovane do procesov iba raz. Pri starte aplikacie sa vytvori tmpfs root, do ktoreho sa mountne checkout aplikacie do /app a checkout frameworku, ktory pouziva, do /usr. Ak ma aplikacia pravo vidiet home adresar, bind mountne sa aj ten, ak ma pravo vidiet dalsie mountpointy, bind mountnu sa aj tie. Teoreticky moze vidiet aj host root, ale nie ako svoj root, ale vo /var/run/host. Nikdy sa nepouzije host rootfs ako rootfs pre aplikaciu.

    V takomto virtualnom filesysteme dostane kazda aplikacia presne to ABI, ktore vo svojom manifeste deklaruje ako potrebne, ale pritom stale je kazdy subor ukladany iba raz a do pamate mapovany iba raz, aj ked ich pouzivaju rozlicne frameworky a aplikacie.