GitHub змяніў метад фармавання аўтаматычна генераваных архіваў ".tar.gz" і ".tgz" на старонках з рэлізамі, што прывяло да змены іх кантрольных сум і масавым збоям у аўтаматызаваных сістэмах зборкі, якія для пацверджання цэласнасці ажыццяўляюць зверку загружаных з GitHub архіваў з раней захаванымі кантрольнымі сумамі, напрыклад, змешчанымі ў метададзеных пакетаў ці ў зборачных сцэнарах.
Пачынальна з выпуску 2.38 у інструментары Git была ўключаная па змаўчанні ўбудаваная рэалізацыя gzip, якая дазваляла ўніфікаваць падтрымку дадзенага метаду сціску ў розных аперацыйных сістэмах і падвысіць прадукцыйнасць стварэння архіваў. GitHub падхапіў змену пасля абнаўлення версіі git у сваёй інфраструктуры. Праблему выклікала тое, што сціснутыя архівы, генераваныя ўбудаванай рэалізацыяй gzip на базе zlib, бінарна адрозніваюцца ад архіваў, створаных утылітай gzip, што прывяло да адрознення кантрольных сум для архіваў, створаных рознымі версіямі git пры выкананні каманды "git archive".
Адпаведна, пасля абнаўлення git у GitHub на старонках рэлізаў сталі аддавацца крыху іншыя архівы, якія не праходзяць праверку па старых кантрольных сумах. Праблема выявілася ў розных зборачных сістэмах, сістэмах бесперапыннай інтэграцыі і ў інструментарыях зборкі пакетаў з зыходных тэкстаў. Напрыклад, парушылася зборка каля 5800 партоў FreeBSD, зыходныя тэксты для якіх загружаліся з GitHub.
У адказ на першыя скаргі аб узніклых збоях прадстаўнікі GitHub спачатку спасылаліся на тое, што пастаянныя кантрольныя сумы для архіваў ніколі не гарантаваліся. Пасля таго, як было паказана, што для аднаўлення працаздольнасці сістэм зборкі, на якія паўплывала змена, запатрабуецца каласальная праца па абнаўленні метададзеных у розных экасістэмах, прадстаўнікі GitHub змянілі сваё меркаванне, адмянілі змену і вярнулі стары метад генерацыі архіваў.
Распрацоўнікі Git пакуль не дашлі да нейкага рашэння і толькі абмяркоўваюць магчымыя дзеянні. Разглядаліся такія варыянты, як адкат на выкарыстанне ўтыліты gzip па змаўчанні; даданне сцяга "-stable" для захавання сумяшчальнасці са старымі архівамі; прывязка ўбудаванай рэалізацыі да асобнага фармату архіва; выкарыстанне ўтыліты gzip для старых комітаў і ўбудаванай рэалізацыі для комітаў, пачынаючы з пэўнай даты; гарантаваньне стабільнасьці фармату толькі для несьціснутых архіваў.
Складанасць прыняцця рашэння тлумачыцца тым, што адкат на выклік вонкавай утыліты цалкам не вырашае праблему нязменнасці кантрольных сум, бо змена ў вонкавай праграме gzip таксама можа прывесці да змены фармату архіва. У цяперашні час для рэцэнзавання прапанаваны набор патчаў, які вяртае па змаўчанні старыя паводзіны (выклік вонкавай утыліты gzip) і выкарыстоўвалы ўбудаваную рэалізацыю пры адсутнасці ў сістэме ўтыліты gzip. Патчы таксама дадаюць у дакументацыю згадванне, што стабільнасць вываду "git archive" не гарантуецца і фармат можа быць зменены ў будучыні.
Крыніца: opennet.ru