Githubissa tehdyt muutokset eivät vastanneet odotuksia
Siitä on äskettäin uutisoitu GitHub on muuttanut tiedostojen luontitapaa Automaattisesti luodut ".tar.gz" ja ".tgz" käynnistyssivuilla.
Tämä muutos aiheutti muutoksia tarkistussummiin ja valtavia kaatumisia rakennusjärjestelmissä automaattiset, jotka tarkistavat GitHubista ladattujen tiedostojen eheyden verrattuna aiemmin tallennettuihin tarkistussummiin, kuten paketin metatietoihin tai koontiskripteihin.
Gitin versiosta 2.38 alkaen mukana oletuksena gzipin integroitu toteutus, Tämä mahdollisti tämän pakkausmenetelmän tuen yhdistämisen kaikissa käyttöjärjestelmissä ja tiedostojen luonnin tehokkuuden parantamisen. GitHub otti muutoksen vastaan päivitettyään infrastruktuurinsa git-version.
Git-tiedostojen oletuspakkaus on hiljattain muuttunut. Tämän seurauksena GitHubista ladatuilla tiedostoilla voi olla erilaiset tarkistussummat, vaikka sisältö ei ole täysin muuttunut.
GitHub ei takaa automaattisesti luotujen tiedostojen tarkistussummien vakautta. Ne on merkitty sanoilla "Lähdekoodi (zip)" ja "Lähdekoodi (tar.gz)" Versiot-välilehdellä. Jos haluat luottaa johdonmukaiseen tarkistussummaan, voit ladata tiedostoja suoraan GitHub-julkaisuihin.
Nämä eivät takuulla muutu.
Ongelma oli kuin tiedostot luotuja tabletteja gzip-toteutuksen avulla zlib build ovat erilaisia binaareja gzip-apuohjelman luomista tiedostoista, mikä johtaa erilaisiin tarkistussummiin arkistoille, jotka on luotu eri git-versioilla, kun "git archive" -komento suoritetaan.
Näin ollen gitin päivittämisen jälkeen GitHubissa, julkaisusivuille alkoi ilmestyä hieman erilaisia tiedostoja joka epäonnistui vahvistuksessa yllä olevilla tarkistussummilla.
Ongelma ilmeni erilaisissa koontijärjestelmissä, jatkuvassa integraatiojärjestelmissä ja työkalupakkeissa pakettien rakentamiseen lähteestä. Esimerkiksi noin 5800 FreeBSD-porttia meni rikki, joiden lähteet ladattiin GitHubista.
Vastauksena ensimmäisiin valituksiin epäonnistumisista, GitHubin edustajat huomauttivat aluksi, että tarkistussummia ei koskaan taattu tiedostojen vakiot.
Sen jälkeen kun osoitettiin, että muutosten vaikutusten kohteena olevien rakennusjärjestelmien tekeminen vaatisi paljon työtä metatietojen päivittämiseksi eri ekosysteemeissä, GitHub muutti mielensä ja palautti muutoksen ja palasi vanhaan tiedostojen luontitapaan.
Odotetusti, ihmiset alkoivat valittaa. Ensimmäinen vastaus GitHubin työntekijältä (ja suurimmalta Git-avustajalta) brian m. Carlson ei ymmärtänyt täysin:
Sanon, että käytäntö ei ole koskaan ollut oikea, emmekä ole koskaan taanneet vakaita tarkistussummia tiedostoille, aivan kuten Git ei ole koskaan taannut sitä. Pahoittelen, että asiat eivät toimi täällä, eikä tästä ole aiemmin tiedotettu selkeämmin, mutta käytäntömme ei ole muuttunut yli neljään vuoteen.
Git Developers he eivät ole vielä tehneet päätöstä ja keskustelevat vain mahdollisista toimista. Las Harkittuja vaihtoehtoja ovat gzip-apuohjelman käyttö oletusarvo; lisäämällä "–stable" -lippu yhteensopivuuden säilyttämiseksi vanhempien tiedostojen kanssa; linkitä sisäänrakennettu toteutus erilliseen tiedostomuotoon; gzip-apuohjelman käyttäminen vanhoille toimituksille ja sisäänrakennetun toteutuksen käyttämiselle tietyn päivämäärän jälkeen; takaa muodon vakauden vain pakkaamattomille tiedostoille.
Päätöksen monimutkaisuus selittyy sillä, että paluu ulkoiseen apuohjelman kutsuun ei täysin ratkaise tarkistussumman invarianssiongelmaa, koska myös ulkoisen gzip-ohjelman muutos voi aiheuttaa muutoksen tiedostoon.
Tällä hetkellä tarkistettavaksi on asetettu korjaustiedosto, joka palaa oletustoimintoon (kutsuu ulkoiseen gzip-apuohjelmaan) ja käyttää sisäänrakennettua toteutusta, kun gzip-apuohjelmaa ei ole järjestelmässä. Korjaukset lisäävät dokumentaatioon myös huomautuksen, että "git arkiston" tulosteen ei voida taata olevan vakaa ja muotoa voidaan muuttaa tulevaisuudessa.
Vihdoin jos olet kiinnostunut tietämään siitä lisää, voit tarkistaa yksityiskohdat seuraava linkki.