GitHub-ലെ ആർക്കൈവ് ചെക്ക്‌സമുകളിലെ മാറ്റങ്ങൾ കാരണം ബിൽഡ് സിസ്റ്റങ്ങളിലെ പരാജയങ്ങൾ

GitHub, റിലീസ് പേജുകളിൽ സ്വയമേവ ജനറേറ്റുചെയ്ത “.tar.gz”, “.tgz” ആർക്കൈവുകൾ സൃഷ്ടിക്കുന്ന രീതി മാറ്റി, ഇത് അവയുടെ ചെക്ക്‌സങ്ങളിൽ മാറ്റങ്ങൾ വരുത്തുകയും സമഗ്രത സ്ഥിരീകരിക്കുന്നതിന് മുമ്പുള്ളവയ്‌ക്കെതിരെ GitHub-ൽ നിന്ന് ഡൗൺലോഡ് ചെയ്‌ത ആർക്കൈവുകൾ പരിശോധിക്കുന്ന ഓട്ടോമേറ്റഡ് ബിൽഡ് സിസ്റ്റങ്ങളിലെ വൻ പരാജയങ്ങൾക്കും കാരണമായി. സംഭരിച്ച ചെക്ക്സം, ഉദാഹരണത്തിന്, പാക്കേജ് മെറ്റാഡാറ്റയിലോ ബിൽഡ് സ്ക്രിപ്റ്റുകളിലോ സ്ഥാപിച്ചിരിക്കുന്നു.

റിലീസ് 2.38 മുതൽ, Git ടൂൾകിറ്റിൽ സ്ഥിരസ്ഥിതിയായി gzip-ന്റെ ഒരു ബിൽറ്റ്-ഇൻ നടപ്പിലാക്കൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, ഇത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിൽ ഉടനീളം ഈ കംപ്രഷൻ രീതിക്കുള്ള പിന്തുണ ഏകീകരിക്കാനും ആർക്കൈവ് സൃഷ്ടിക്കൽ പ്രകടനം മെച്ചപ്പെടുത്താനും സാധ്യമാക്കി. GitHub അതിന്റെ ഇൻഫ്രാസ്ട്രക്ചറിലെ git പതിപ്പ് അപ്‌ഡേറ്റ് ചെയ്‌തതിന് ശേഷമാണ് മാറ്റം സ്വീകരിച്ചത്. ബിൽറ്റ്-ഇൻ zlib-അടിസ്ഥാനത്തിലുള്ള gzip നടപ്പിലാക്കൽ സൃഷ്ടിച്ച കംപ്രസ് ചെയ്ത ആർക്കൈവുകൾ gzip യൂട്ടിലിറ്റി സൃഷ്ടിച്ച ആർക്കൈവുകളിൽ നിന്ന് ബൈനറി വ്യത്യസ്തമാണ് എന്ന വസ്തുതയാണ് പ്രശ്‌നത്തിന് കാരണമായത്. "git ആർക്കൈവ്" കമാൻഡ്.

അതനുസരിച്ച്, GitHub-ൽ git അപ്‌ഡേറ്റ് ചെയ്‌തതിനുശേഷം, റിലീസ് പേജുകളിൽ അല്പം വ്യത്യസ്തമായ ആർക്കൈവുകൾ പ്രദർശിപ്പിക്കാൻ തുടങ്ങി, അത് പഴയ ചെക്ക്‌സം ഉപയോഗിച്ച് സ്ഥിരീകരണം പാസാക്കില്ല. വിവിധ ബിൽഡ് സിസ്റ്റങ്ങൾ, തുടർച്ചയായ സംയോജന സംവിധാനങ്ങൾ, സോഴ്സ് കോഡിൽ നിന്ന് പാക്കേജുകൾ നിർമ്മിക്കുന്നതിനുള്ള ഉപകരണങ്ങൾ എന്നിവയിൽ പ്രശ്നം പ്രകടമായി. ഉദാഹരണത്തിന്, ഏകദേശം 5800 FreeBSD പോർട്ടുകളുടെ അസംബ്ലി, GitHub-ൽ നിന്ന് ഡൗൺലോഡ് ചെയ്ത സോഴ്‌സ് കോഡുകൾ തകർന്നു.

തകരാറുകളെക്കുറിച്ചുള്ള പ്രാഥമിക പരാതികൾക്ക് മറുപടിയായി, ആർക്കൈവുകൾക്കുള്ള സ്ഥിരമായ ചെക്ക്സം ഒരിക്കലും ഉറപ്പുനൽകുന്നില്ല എന്ന വസ്തുത GitHub തുടക്കത്തിൽ ഉദ്ധരിച്ചു. ബാധിത ബിൽഡ് സിസ്റ്റങ്ങളുടെ പ്രവർത്തനം പുനഃസ്ഥാപിക്കുന്നതിന് വിവിധ ഇക്കോസിസ്റ്റമുകളിലെ മെറ്റാഡാറ്റ അപ്ഡേറ്റ് ചെയ്യുന്നതിന് വൻതോതിൽ ജോലികൾ ആവശ്യമായി വരുമെന്ന് കാണിച്ചതിന് ശേഷം, GitHub പ്രതിനിധികൾ അവരുടെ മനസ്സ് മാറ്റി, മാറ്റം പഴയപടിയാക്കി, ആർക്കൈവുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള പഴയ രീതി തിരികെ നൽകി.

Git ഡെവലപ്പർമാർ ഇതുവരെ ഒരു തീരുമാനത്തിലെത്തിയിട്ടില്ല, സാധ്യമായ പ്രവർത്തനങ്ങളെക്കുറിച്ച് മാത്രമാണ് ചർച്ച ചെയ്യുന്നത്. ഡിഫോൾട്ട് ജിസിപ്പ് യൂട്ടിലിറ്റി ഉപയോഗിക്കുന്നതിനുള്ള പുനഃസ്ഥാപിക്കുന്നതും പരിഗണിക്കപ്പെടുന്ന ഓപ്ഷനുകളിൽ ഉൾപ്പെടുന്നു; പഴയ ആർക്കൈവുകളുമായി അനുയോജ്യത നിലനിർത്താൻ "--സ്റ്റേബിൾ" ഫ്ലാഗ് ചേർക്കുന്നു; ഒരു പ്രത്യേക ആർക്കൈവ് ഫോർമാറ്റിലേക്ക് ബിൽറ്റ്-ഇൻ നടപ്പിലാക്കൽ ലിങ്ക് ചെയ്യുന്നു; പഴയ കമ്മിറ്റുകൾക്കായി gzip യൂട്ടിലിറ്റിയും ഒരു നിശ്ചിത തീയതി മുതൽ ആരംഭിക്കുന്ന കമ്മിറ്റുകൾക്കുള്ള ഇൻലൈൻ നടപ്പിലാക്കലും; കംപ്രസ് ചെയ്യാത്ത ആർക്കൈവുകൾക്ക് മാത്രം ഫോർമാറ്റ് സ്ഥിരത ഉറപ്പ് നൽകുന്നു.

ബാഹ്യ ജിസിപ്പ് പ്രോഗ്രാമിലെ മാറ്റവും ആർക്കൈവ് ഫോർമാറ്റിൽ മാറ്റത്തിന് കാരണമാകുമെന്നതിനാൽ, ഒരു ബാഹ്യ യൂട്ടിലിറ്റിയിലേക്കുള്ള കോളിലേക്ക് തിരികെ പോകുന്നത് ചെക്ക്സം മാറ്റമില്ലാത്ത പ്രശ്നം പൂർണ്ണമായും പരിഹരിക്കുന്നില്ല എന്ന വസ്തുതയാണ് ഒരു തീരുമാനമെടുക്കുന്നതിനുള്ള ബുദ്ധിമുട്ട് വിശദീകരിക്കുന്നത്. നിലവിൽ, പഴയ സ്വഭാവം സ്ഥിരസ്ഥിതിയായി നൽകുന്ന ഒരു കൂട്ടം പാച്ചുകൾ അവലോകനത്തിനായി നിർദ്ദേശിച്ചിട്ടുണ്ട് (ഒരു ബാഹ്യ gzip യൂട്ടിലിറ്റി എന്ന് വിളിക്കുന്നു) കൂടാതെ സിസ്റ്റത്തിൽ ഒരു gzip യൂട്ടിലിറ്റിയുടെ അഭാവത്തിൽ ബിൽറ്റ്-ഇൻ നടപ്പിലാക്കൽ ഉപയോഗിക്കുന്നു. "ജിറ്റ് ആർക്കൈവ്" ഔട്ട്‌പുട്ടിന്റെ സ്ഥിരത ഉറപ്പുനൽകുന്നില്ലെന്നും ഭാവിയിൽ ഫോർമാറ്റ് മാറിയേക്കാമെന്നും പാച്ചുകൾ ഡോക്യുമെന്റേഷനിൽ പരാമർശിക്കുന്നു.

അവലംബം: opennet.ru