Ohanterliga paket

Datorsystem som kör Unixliknande operativsystem utmärker sig genom att de i stor utsträckning använder sig av pakethanterare för att hålla reda på den mjukvara som finns installerad. Det vanligaste är att paketen innehåller mjukvara i binärt format, som har byggts från källkod med de verktyg som också tillhandahålls av pakethanteraren. Om pakethanteraren konsekvent används för att installera mjukvara går det att med ett kommando hålla systemet uppdaterat med en uppsättning program som är gjorda för att inte komma i konflikt med varandra, och risken att få in skadlig kod minskar. Det har sagts att detta slags pakethantering är det största enskilda framsteg som Linux medfört för industrin (Murdock 2007).

Olika system har olika praxis för hur deras paketförråd hålls uppdaterade. Vissa, som CentOS, är mer konservativa och kan ha relativt gamla programversioner i paketen. Andra, som Arch Linux, satsar på att ha med de senaste stabila versionerna. Den förra typen av system kan ofta passa bättre för servrar, där det har hög prioritet att undvika driftstörningar till följd av otillräckligt testade program. Jag har sedan 2013 använt Arch som primärt system på de laptops där jag fått möjlighet att välja: det har kombinerat uppdaterade programversioner med rimligt god stabilitet för ett personligt system.

Nu i augusti har Julia, ett språk jag använt en del för dataanalys, kommit i version 1.0 (efter att tidigare i legat på 0.x). Det har sin egen pakethanterare, som installerar paket med funktionalitet för språket, oberoende av systemet. En stor andel av alla paket som finns tillgängliga för Julia är direkt eller indirekt beroende av Arpack, ett bibliotek skrivet i Fortran med funktioner för egenvärdesproblem. Efter att jag installerat Julia 1.0 från Archs paketförråd gick inga sådana paket att använda. Arpack går också att installera från Archs paketförråd, men Julias nya system för pakethantering har en funktionalitet, BinaryProvider, som laddar ned färdigbyggda binära beroenden som behövs för Juliapaket och ignorerar motsvarande filer som redan finns installerade i systemet.

Problemet i detta fall är att den färdigbyggda versionen av Arpack, liksom de officiella binära versionerna av Julia för Linux, har byggts med GCC 7, och Arpack är dynamiskt länkad med biblioteket libgfortran.so.4, medan versionerna i Archs paketförråd är byggda med GCC 8, som använder libgfortran.so.5. Jag kunde få Arpack att fungera i Julia genom att manuellt kopiera Archversionen av Arpack till katalogstrukturen under Julias pakethanterare. Det är tydligt att flera andra användare haft liknande problem (JuliaLinearAlgebra 2018). Utvecklarna av BinaryProvider säger bara att de rekommenderar de officiella binärversionerna av Julia över sådana som installerats via systemets pakethanterare (JuliaPackaging 2018). Som motivering bakom systemet anges att de vill undvika problem med föråldrade systembibliotek. Men i detta fall handlar det om att Arch erbjuder bättre uppdaterade versioner än de officiella Juliaversionerna, genom att de är byggda med en nyare (men fortfarande stabil) version av GCC. Det är inte rimligt att ge upp fördelarna med att hantera programvara via systemets pakethanterare i en sådan situation.¹

Samtidigt är det klart att situationen med olika pakethanterare komplicerar sådant som testning av mjukvara och kan vara problematisk inte minst för vetenskaplig mjukvara, med behovet av reproducerbarhet hos resultat. Vissa har föreslagit lösningar med ytterligare abstraktioner för att möjliggöra enhetlig uppdatering av program och deras beroenden oberoende av operativsystemet (Poettering 2014); jag vet inte vad som blivit av detta. Med dagens situation, kunde inte Julia använda sig av systemets versioner så länge de inte är äldre än de versioner som erbjuds av BinaryProvider (den strategi som används av exempelvis Vepsäläinen (2018)), eller använda statisk länkning för de senare (vilket Cheplyaka (2016) förespråkar för vetenskaplig mjukvara i allmänhet)?

Det finns en del andra problem jag stött på i Julia 1.0; mitt Mortchartgen gav upphov till segmenteringsfel vid kompileringen, som verkar vara relaterade till PyCall-paketet (PyJulia 2018), som jag använder för att anropa Bokeh. Också när det gäller PyCall har flera andra rapporterat liknande problem. Jag håller på att skriva om Mortchartgen, så att funktionerna för att generera datatabeller för diagrammen görs oberoende av själva skapandet av diagrammen (något jag tänkt göra tidigare). Den förra funktionaliteten behöver inte anropa Python, och när anropen till PyCall stängts av verkar det fungera bra.

Referenser

---

1. Att använda systemets pakethanterare är tydligen som att låta bli att ta folk i hand i förkylningstider: en sund praxis som kan göra en utsatt för skäll. I en tweet häromdagen klagade en representant för Ungsvenskarna på att företrädaren för Ung Vänster vägrat ta henne i hand vid en debatt, samtidigt som hon i samma tweet skrev att hon hade feber vid just det tillfället (Frick 2018).↩︎

Webbplatsen drivs av Karl Pettersson och har genererats med Hakyll. Källkod. Kakor används vid kommentering med Isso, för att möjliggöra editering av kommentarer inom 15 minuter efter att de postats, vilket inte kommer att fungera korrekt om kakor stängs av i webbläsaren. Kommentarer som skickas sparas för att publiceras med namn och webbsida, om dessa angetts: en fungerande e-postadress kan, om så önskas, anges för att få möjlighet att kommunicera kring kommentaren i efterhand men publiceras inte. Om JavaScript inaktiveras, kommer varken kommentarer eller visning av formler med MathJax att fungera. Om fel uppstår vid besök, kan uppgifter om besökares IP-adress och tid för felet lagras i interna loggar och användas vid felsökning.