Ar trebui să pun aplicația în /usr/local sau /usr/local/share? (Unix, Instalare Software, Structură De Directoare, Aplicație)

greenoldman a intrebat.

Care sunt „standardele” — ar trebui să pun aplicația (nu doar binară, ci întreaga distribuție) în /usr/local sau /usr/local/share.

De exemplu scala sau weka — conține exemple, binare, biblioteci și așa mai departe. Așadar, ar fi

/usr/local/scala-2.9.1 

sau

/usr/local/share/scala-2.9.1

Din moment ce sunt singurul administrator, nu este o mare problemă pentru mine, dar prefer să folosesc ceva care este utilizat pe scară largă, nu cu propriile mele obiceiuri.

Important: Nu vă întreb despre cazurile în care ar trebui să împărțiți aplicația în /usr/local/bin, /usr/local/lib și așa mai departe. Mai degrabă întreb despre cazul în care trebuie să păstrați un singur director principal pentru întreaga aplicație.

Comentarii

  • Cred că /opt este mai obișnuit în acest tip de context. –  > Por Faheem Mitha.
  • @Faheem Mitha, foarte bună observație. Mulțumită ție am găsit o astfel de explicație „/opt/’provider’ directory tree, similar cu modul în care Windows va instala noul software în propriul său director tree C:WindowsProgam Files
    Program Name” din linuxtopia.org/online_books/linux_beginner_books/… Ați putea vă rog să postați comentariul dvs. ca răspuns, astfel încât să îl marchez ca fiind răspunsul? Vă mulțumesc. –  > Por greenoldman.
  • @greenoldman: de asemenea te rog realizați că păstrarea tuturor fișierelor într-un singur dir este nu modul „standard” de a instala aplicații în Unix. /opt este, într-adevăr, răspunsul corect, dar este nu „utilizat pe scară largă” de software-ul tradițional Unix/Linux. Există motive întemeiate pentru a vă împărți fișierele în mai multe directoare și, de asemenea, pentru a diferenția /usr de /usr/local –  > Por MestreLion.
  • De exemplu, păstrarea tuturor executabilelor din toate aplicațiile într-un singur /usr/bin (sau /usr/local/bin) permite ca $PATH-ul dvs. să ajungă la toate programele fără a fi nevoie să îl editați pentru fiecare program, un concept care nu există în Windows –  > Por MestreLion.
4 răspunsuri
Faheem Mitha

Cred că /opt este mai standard în acest tip de context. Secțiunea relevantă din Standardul de ierarhie a sistemului de fișiere este citată mai jos.

Distribuțiile pot instala software în /opt, dar nu trebuie să modifice sau să șteargă software-ul instalat de administratorul de sistem local fără acordul acestuia.

 Justificare Utilizarea /opt pentru software suplimentar este o practică bine stabilită în comunitatea UNIX. Interfața System V Application Binary Interface [AT&T 1990], bazată pe System V Interface Definition (ediția a treia), prevede o structură /opt foarte asemănătoare cu cea definită aici.

Standardul Intel Binary Compatibility Standard v. 2 (iBCS2) prevede, de asemenea, o structură similară pentru /opt.

În general, toate datele necesare pentru a susține un pachet pe un sistem trebuie să fie prezente în /opt/, inclusiv fișierele destinate a fi copiate în /etc/opt/ și /var/opt/, precum și directoarele rezervate din /opt.

Restricțiile minore privind distribuțiile care utilizează /opt sunt necesare deoarece sunt posibile conflicte între software-ul instalat în distribuție și cel instalat local, în special în cazul numelor de drumuri fixe găsite în unele programe binare.

Structura directoarelor de sub /opt/ este lăsată la latitudinea celui care împachetează software-ul, deși se recomandă ca pachetele să fie instalate în /opt// și să urmeze o structură similară cu orientările pentru /opt/package. Un motiv valabil pentru a se abate de la această structură este reprezentat de pachetele de asistență care pot avea fișiere instalate în /opt//lib sau /opt//bin.

symcbean

Ar trebui să utilizați numai /usr/local/share pentru fișierele care nu sunt specifice unei anumite arhitecturi / versiuni de sistem de operare.

După aceea, depinde de dumneavoastră dacă distribuiți fișierele între subdirectoarele existente din /usr/local sau dacă creați un nou director dedicat în /usr/local (dar acesta din urmă nu va exista deja pe executabilul PATH, , în cazul în care LD_LIBRARY_PATH, , nici pe MANPATH).

Aruncați o privire la FHS

Comentarii

  • Vă mulțumim. Deci, dacă este o analogie din Windows, ar trebui să fie /usr/local/SPECIAL_APP și înăuntru ar trebui să fie subdirectoarele sale, nu? –  > Por greenoldman.
  • @greenoldman: nu. Nici o analogie nu se va potrivi pentru că Windows și Linux folosesc modele diferite: În Windows, de obicei, păstrați toate fișierele într-un singur dir, în timp ce în Linux, de obicei, le împărțiți pe bin, , share, , lib, , etc –  > Por MestreLion.
Teddy

Până la /opt a devenit comună, locul obișnuit era /usr/local/lib/<package>.

Comentarii

  • Din ce am citit, /opt este destul de comun, doar că nu este folosit pe scară largă, dar asta nu este o surpriză dacă ne gândim la cantitatea de pachete disponibile în depozite. –  > Por greenoldman.
Iden Ilraldeduk

Atunci când instalați aplicații locale, există mai multe opțiuni în funcție de modul în care doriți să accesați și să actualizați. De asemenea, trebuie remarcat faptul că unele metode seamănă mai mult cu sistemul pe care îl aveți deja, iar altele sunt mai ad-hoc. Aș sugera că „cele mai bune” soluții sunt cele care fac lucrurile mai ușor de gestionat.

Am împărțit acest răspuns în funcție de numărul de pachete pentru care se fac instalări personalizate. Împărțirea se bazează pe propriile mele experiențe. Aceste experiențe pun în balanță timpul necesar pentru a gestiona pachetele și riscurile de a strica ceva. Nu vreau să spun că am cunoștințe despre standardele comune, ci vreau să spun că acesta este un punct de referință la care să vă uitați atunci când luați decizia.

Pentru doar câteva pachete,aș vrea să pun pachete suplimentare în /opt, , unde nu se află în calea tuturor celorlalte, astfel încât nimic să nu le încurce și ele să poată încurca altceva. Aceasta este metoda pe care o folosesc pe NAS-ul meu. Totuși, această metodă ține binarele în afara PATH-ului, așa că va trebui să le adăugați manual. Acest lucru funcționează bine dacă sunt doar câteva pachete de instalat, dar devine o adevărată încurcătură dacă sunt multe.

Actualizarea aici este destul de ușoară, deoarece trebuie doar să suprascrieți directorul.

Pro:

  • simplu
  • rapid de instalat
  • nu există riscul de a afecta alte părți ale sistemului
  • dezinstalarea este la fel de ușoară ca și instalarea

Contra:

  • Devine destul de anevoios dacă numărul de pachete de instalat este mare
  • Face PATH un aspect dezordonat

Pentru mai mult de câteva pachete, , aș recomanda să folosiți opțiunea /usr/local/<your package> și conectarea prin sym-linking a executabilului din /usr/local/bin sau /usr/local/sbin în funcție de faptul dacă aveți nevoie de privilegii de root. Acest lucru vă scutește de schimbarea PATH-ului de fiecare dată când se adaugă ceva nou, astfel încât PATH-ul rămâne curat. Aceasta este metoda pe care o folosesc pe laptopul meu Arch pentru toate pachetele non-pacman și pachetele AUR.

Actualizarea se face prin suprascrierea directorului pachetului și verificarea faptului că legătura simbolică este încă valabilă și repararea acesteia dacă nu este.

Pro

  • Nu face PATH mizerie
  • Nu afectează sistemul de bază
  • Încă foarte simplu de eliminat toate suplimentele și de revenit la un sistem de bază curat

Contra:

  • Mai multă muncă pentru configurare
  • Îndepărtarea unui singur pachet necesită ceva căutări

Pentru mai multe pachete. Deoarece nu acesta este cazul pe care îl doriți, voi fi scurt. V-aș recomanda să împărțiți pachetul în bin, , lib,share, , etc. și să le instalați în /usr/local. Asta pentru a păstra structura curată. De asemenea, puteți specifica cine poate scrie unde și multe altele. De exemplu, nu doriți ca alte persoane decât root să modifice executabilul.

Aici actualizarea devine puțin mai complicată, deoarece trebuie să scrieți în mai mult de un singur director. V-aș recomanda să împachetați totul și să lăsați managerul de pachete să se ocupe de restul.

Share

share în sine este destinat fișierelor independente de arhitectură, așa cum se arată în articolul lui Faheem link iar fișierele care depind de arhitectură trebuie să meargă la lib, , lib32, , lib64, , etc.

Comentarii

  • Oferirea de sfaturi bazate pe numărul de pachete nu este utilă; cum pot ști din ce grup face parte pachetul meu? –  > Por Alois Mahdal.
  • De asemenea, atunci când spuneți „este recomandat”, menționați sursa de referință sau precizați clar că este recomandarea dvs. (presupun că aceasta din urmă…?) – –  > Por Alois Mahdal.
  • Și, apropo, nu văd cum în /opt ar fi mai puține șanse ca lucrurile să îți strice aplicația decât atunci când este răspândită în /usr etc. A da peste cap alte aplicații este mush mai mult despre numirea corectă a lucrurilor și despre a nu avea bug-uri în scripturile de instalare. –  > Por Alois Mahdal.
  • Cu siguranță este vorba despre denumire, ceea ce face ca lucrurile să fie încurcate. Este un lucru pe care l-am experimentat și eu în trecut și de aceea îmi place să țin pachetele mele „extra” departe de toate celelalte. Totuși, nu vreau să facă lucrurile să arate urât. –  > Por Iden Ilraldeduk.
  • Și da, aveți dreptate în ceea ce privește „este recomandat”, după cum puteți vedea din răspunsul meu, am folosit „aș recomanda” peste tot în rest. Acum mi-am corectat ortografia și am lămurit de ce aș recomanda ceva. Din nou, este doar perspectiva mea și nu este menit să fie un răspuns definitiv. –  > Por Iden Ilraldeduk.