GitHub muutti tapaa, jolla se luo automaattisesti luotuja ".tar.gz"- ja ".tgz"-arkistoja julkaisusivuilla, mikä johti muutoksiin niiden tarkistussummissa ja valtaviin virheisiin automaattisissa rakennusjärjestelmissä, jotka tarkistavat GitHubista ladatut arkistot aiempien arkiston eheyden varmistamiseksi. Tallennetut tarkistussummat, esimerkiksi sijoitettuna paketin metatietoihin tai koontiskripteihin.
Julkaisusta 2.38 alkaen Git-työkalupakki sisälsi oletuksena sisäänrakennetun gzipin toteutuksen, mikä mahdollisti tämän pakkausmenetelmän tuen yhdistämisen eri käyttöjärjestelmissä ja arkiston luomisen tehokkuuden parantamisen. GitHub otti muutoksen vastaan päivitettyään git-version infrastruktuurissaan. Ongelma johtui siitä, että sisäänrakennetun zlib-pohjaisen gzip-toteutuksen luomat pakatut arkistot eroavat binaarisesti gzip-apuohjelman luomista arkistoista, mikä johti erilaisiin tarkistussummiin gitin eri versioiden luomille arkistoille suoritettaessa "git archive" -komento.
Vastaavasti git-päivityksen jälkeen GitHubissa julkaisusivuilla alkoi näkyä hieman erilaisia arkistoja, jotka eivät läpäisseet tarkistusta vanhoilla tarkistussummilla. Ongelma ilmeni erilaisissa koontijärjestelmissä, jatkuvassa integraatiojärjestelmissä sekä työkaluissa pakettien rakentamiseen lähdekoodista. Esimerkiksi noin 5800 FreeBSD-portin kokoonpano, joiden lähdekoodit ladattiin GitHubista, meni rikki.
Vastauksena alkuperäisiin virheisiin liittyviin valituksiin GitHub mainitsi alun perin tosiasian, että arkistojen pysyviä tarkistussummia ei koskaan taattu. Sen jälkeen kun kävi ilmi, että metatietojen päivittäminen eri ekosysteemeissä vaatisi valtavasti työtä, jotta sairastuneiden koontijärjestelmien toimivuus palautettaisiin, GitHubin edustajat muuttivat mielensä, peruuttivat muutoksen ja palasivat vanhaan arkistojen luomiseen.
Git-kehittäjät eivät ole vielä tehneet päätöstä ja keskustelevat vain mahdollisista toimista. Tarkasteltuihin vaihtoehtoihin kuului paluu gzip-oletusapuohjelman käyttöön; "--stable"-lipun lisääminen yhteensopivuuden säilyttämiseksi vanhojen arkistojen kanssa; linkitetään sisäänrakennettu toteutus erilliseen arkistomuotoon; gzip-apuohjelman käyttö vanhoille toimituksille ja inline-toteutukselle tietystä päivämäärästä alkaen; takaa muodon vakauden vain pakkaamattomille arkistoille.
Päätöksenteon vaikeus selittyy sillä, että paluu ulkoisen apuohjelman kutsuun ei täysin ratkaise tarkistussumman muuttumattomuuden ongelmaa, koska muutos ulkoisessa gzip-ohjelmassa voi johtaa myös arkistomuodon muutokseen. Tällä hetkellä tarkistettavaksi on ehdotettu joukko korjaustiedostoja, jotka palauttavat vanhan toiminnan oletusarvoisesti (kutsuvat ulkoista gzip-apuohjelmaa) ja käyttävät sisäänrakennettua toteutusta, jos järjestelmässä ei ole gzip-apuohjelmaa. Korjaukset lisäävät dokumentaatioon myös maininnan, että "git arkiston" lähdön vakautta ei taata ja muoto saattaa muuttua tulevaisuudessa.
Lähde: opennet.ru