Pangalan ng distro, glibc o compiler: ano ang sinusuri ng installer

Nagpi-print ang installer ng “unsupported distribution”, babaguhin mo ang isang string, at magpapatuloy ito hanggang mabigo pagkaraan ng isang minuto na may error ng loader. Ang pagkakasunod-sunod na iyon ang sintomas na dapat makilala: ang unang pagpalya ay check ng pagkilala at ang pangalawa ay hangganan ng compatibility. Dalawang magkaibang problema sila na nagkataong lumilitaw sa isang terminal. Ang pag-edit sa check ay makakapaglipat lang sa iyo mula sa una hanggang sa pangalawa.

Ang sintomas: humihinto ang installer sa iyong derivative

Ang script na nagbabasa ng pangalan ng distribution at tumatanggi nang magpatuloy ay nagsasabi sa iyo na hindi sinubukan ng may-akda nito ang iyong derivative. Pahayag iyon ng suporta at hindi teknikal na katotohanan, at madalas itong mali sa diwa na gagana nang maayos ang package.

Nagsisimula ang gulo kapag ang pansamantalang solusyon ang naging plano. Ang pagbabago ng identity file ay nagpapalusot sa check, at pagkatapos ay lumo-load ang package, o hindi, laban sa runtime na talagang naka-install. Kung mabigo roon, walang karagdagang pag-edit ng identity ang makakatulong.

Kaya ang kapaki-pakinabang na hakbang ay alamin kung anong tanong ang itinanong ng installer, at pagkatapos ay alamin kung ang sagot ay may halaga. Dalawang hiwalay na imbestigasyon ito at ang pangalawa lang ang humuhula kung gagana ang package.

Tatlong bersyon na tinatawag ng mga tao na bersyon ng system

Ang release ng distribution ay nagpapangalan ng naka-package na kapaligiran. Ang bersyon ng C library ay nagpapangalan ng implementasyon ng runtime at ng release nito. Ang bersyon ng compiler ay nagpapangalan ng toolchain. Sa usapan, tinatawag ng mga tao ang tatlo na “bersyon ng system”, at sa isang installer hindi sila mapagpapalit.

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

Ang application na na-build nang maaga ay umaasa sa runtime na umiiral nang i-link ito. Ang pagpapalit ng mga compiler sa host ay hindi ito nagli-link muli, at ang mas bagong toolchain ay walang binabago sa mga simbolo ng loader na hinihiling ng binary. Mahalaga muli ang arkitektura nang hiwalay, dahil ang 32-bit na package sa 64-bit na system ay nabibigo sa mga dahilang walang string ng bersyon ang nakapagpapaliwanag.

Itabi ang apat na output kasama ng ulat. Sampung segundo lang ang pagkolekta nito at sinasagot nila ang karamihan ng tanong na itatanong sa iyo ng maintainer sa email.

Basahin ang error, hindi ang check

Ang unang error sa paglunsad ang ebidensya. Ang mensahe tungkol sa nawawalang shared object, o tungkol sa bersyon ng simbolo na hindi kayang tugunan ng loader, ay problema sa dependency ng runtime. Ang mensaheng umuulit sa pangalan ng distribution ay muli ang check ng pagkilala, sa ibang lugar.

Inilalarawan ng dokumentasyon ng dynamic na linker kung paano gumagana ang paghahanap ng library at saan naghahanap ang loader. Ang pagbabago ng label ng distribution ay hindi nagdadagdag ng direktoryo sa landas ng paghahanap na iyon, kaya mukhang walang kaugnayan ang pangalawang pagpalya sa una.

Huwag gamitin ang ldd sa na-download na executable bilang ordinaryong unang hakbang. Nagbabala mismo ang manwal nito na maaari nitong patakbuhin ang programa sa ilang pagkakataon, at ang pagpapatakbo ng hindi pinagkakatiwalaang installer ay siya mismong kaso na tinutukoy ng babalang iyon.

Bakit hindi nakakatulong ang pag-edit ng string

Ang pagpeke sa identity ng operating system ay nagbabago kung paano tinitingnan ng bawat programa sa makina ang sarili nito. Nagbabasa ng parehong file ang mga package manager, support tool at iba pang application, at ang halagang nakakapagbigay-kasiyahan sa isang installer ay maaaring makalito ng ibang bagay makalipas ang mga buwan.

Ang pagpapalit ng mga library ng host ng mga file mula sa ibang distribution ay mas masama. Maaari nitong sirain ang walang kaugnayang software, hindi ito nakikita ng package manager, at nangangailangan ito ng planong pang-maintenance na walang nagsusulat. Hindi nabibigyang-katuwiran ang mga pagbabagong iyon ng isang mahigpit na installer.

Kung tunay na depekto ng pagkilala ang check, makukumpirma ito ng maintainer at mailalarawan ang sinusuportahang pagwawasto. Kung hindi depekto, ang sinusuportahang landas ay isang build para sa iyong platform, at hindi nagbabago ang sagot na iyon dahil na-edit ang string.

Sumulat ng ulat na maaaring pagbatayan ng maintainer

Itala ang distribution at release, arkitektura, release ng VPN, ang eksaktong kondisyong tinanggihan, at ang unang error ng runtime kung umabot ka doon. Isulat kung may binago ka, dahil ibang ulat ang ulat mula sa binagong system.

Iwanang hindi binago ang orihinal na installer at ilarawan ang check sa halip na lusutan ito. Ang pagkakaibang iyon ang nagpapahintulot sa maintainer na ihiwalay ang masyadong makitid na tuntunin ng pagkilala mula sa tunay na hangganan ng binary compatibility, at dalawang magkaibang bug iyon na may dalawang magkaibang pagwawasto.

Kung ang sagot ay hindi sinusuportahan ang iyong platform, kapaki-pakinabang na resulta iyon. Sinasabi nitong maghanap ka ng sinusuportahang build sa halip na gumugol ng isa pang gabi sa mga identity file na hindi kailanman naging problema.