13. heinäkuuta 2020

Mielipide: Linuxin pakettimanagerit


Linuxin pakettimanagerit eli alustat, joiden avulla hallitaan Linux jakeluiden sovellusasennuksia, ovat yleensä olleet se, jolla jakelut eroavat näkyvimmin toisistaan.

Red Hat pohjaiset jakelut käyttävät yleisesti RPM pakettimanageria.
Debian pohjaiset jakelut käyttävät DEB pakettimanageria.
ARCH Linux pohjaiset jakelut käyttävät PACMAN pakettimanageria.

Maailmalla olisi kova halu yhtenäistää pakettimanagerit mutta nykyinen trendi haluaa tehdä selkeän eron perinteisiin managereihin, sillä että ne haluavat syöttää sovellukset järjestelmälle, eräänlaisessa suojakääreessä joka taas hidastaa sovelluksen käynnistymistä sekä yleistä toimintaa, sekä toimittaa paketti varmatoimisena, joka tarkoittaa sitä että sovellus ei enää kunnioita järjestelmästä jo löytyviä komponentteja vaan paketin sisällä toimitetaan kaikki mitä kehittäjä on katsonut ohjelman tarvitsevan.

Tämä taas aiheuttaa sen että kyseiset komponentit ovat yleisesti ottaen vanhoja versioita, jotka eivät tue viimeisimpiä parannuksia, mikäli pakettiin ei ole, sen ylläpitäjän toimesta toimitettu uudempia komponentteja (kirjastoja, apuohjelmia…) jotka nämä parannukset sisältävät.

Universaalit pakettimanagerit myös eroavat toisistaan, vaikka useamassa onkin periaatteessa sama idea, ovat ne luonnollisesti epäyhteensopivia keskenään. Tällä hetkellä Linux maailmassa on kolmea erilaista (itse asiassa neljä jos pip otetaan mukaan) universaalia paketointia:

SNAP
FLATPAK
APPIMAGE

Näistä APPIMAGE on ehkä varmatoimisin mutta samalla siitä uupuu keskitetty hallinta, joka tarkoittaa sitä, että tiedosto pitää erikseen ladata esimerkiksi kehittäjän kotisivuilta, kuten Windows maailmassa. Kyseessä on nimensä mukaisesti levykuva, jonka käynnistämällä avataan sovellus, jonka se sisältää, samalla kyseinen tiedosto on yleisesti todella suuri kooltaan, eikä Appimageja voi suoranaisesti liittää työpöytien sovellusvalikkoon, muuta kuin käsin asettamalla.

FLATPAK taas tukee keskitettyä hallintaa, Flatpakit on myös päivitettävissä uusiin, toisin kuin Appimaget. Teknisesti ottaen kuitenkin Flatpak jakaa paljon Appimagen kanssa mutta on muutamia askelia sitä edellä muun muassa työpöytään integroitumisessa.

SNAP on Ubuntun kehittäjän, Canonicalin vastaus haasteeseen, se muistuttaa hyvin paljon perinteisempää pakettihallintaa mutta käynnistää sovellukset edelleen hitaaseen virtuaalikoneen kaltaiseen hiekkalaatikkoon, sen asennuspalvelimet ovat usein hitaita ja varsinkin pakettien päivitys vaikuttaa usein olevan mahdotonta.

Maailmalla Flatpak näyttää saaneen eniten suosiota, varmasti sen integroitumisen vuoksi ja myös siksi että se vaikuttaa olevan enemmän vapaa muista suurista softataloista, toisin kuin esimerkiksi Snap.

EI VALMIITA TYÖPÖYDÄLLE:

Tässä ovat myös syyt miksi katson, etteivät nämä nykyiset universaalit paketoinnit ole valmiita työpöydille. Onkin suoranaisesti hullua nähdä sovellusprojekteja, joiden kehittäjät eivät julkaise sovelluksestaan muuta kuin Appimagen. Linux yhteisön on hyvin vaikea näihin puuttua ja luoda itse deb tai rpm paketteja kyseisistä ohjelmista, koska näiden kehittäjät eivät useinkaan myös suostu dokumentaatioissaan mainita mitä riippuvuuksia ohjelma tarvitsee toimiakseen tai edes kääntyäkseen ohjelmakoodista.

Koska näitä tietoja ei sellaisenaan tarjota ja ne tarvitsee usein selvittää itse, voi olla melko varma ettei vaikkapa deb paketin ylläpitäjä jaksa enää vaivautua ohjelman uuden version kääntämiseen ja siten saattamista sitä deb tai rpm pakettiin.

Onko siis nämä universaalit paketoinnit tehneet kehittäjistä puhtaasti laiskempia, ehkä?

Onhan se periaatteessa myös yksi syy näiden olemassa oloon, tehdä ohjelmien levittämisestä helpompaa ja suoraviivaisempaa, enkä väitä etteikö se sitä olisi tehnyt.

Ongelma on vain siinä että työpöytä ja nämä vaihtoehdot eivät ole vielä samalla aaltopituudella ja siksi olisi edelleen hyvin tärkeää että ohjelmistokehittäjät pitäisivät standardina, kertoa dokumentoinnissa edelleen selkeästi kuinka ohjelmat voidaan kääntää suoraan lähdekoodista ja mitä komponentteja se vaatii.