Apa perbedaan antara / opt dan / usr / local?

404

Menurut Standar Hierarki Filesystem , /optadalah untuk "instalasi paket perangkat lunak aplikasi tambahan". /usr/localadalah "untuk digunakan oleh administrator sistem ketika menginstal perangkat lunak secara lokal". Kasing ini tampaknya sangat mirip. Perangkat lunak yang tidak termasuk dalam distribusi biasanya dikonfigurasikan secara default untuk menginstal di salah satu /usr/localatau /opttanpa sajak atau alasan tertentu yang mereka pilih.

Apakah ada beberapa perbedaan yang saya lewatkan, atau keduanya melakukan hal yang sama, tetapi ada karena alasan historis?

directory-structure fhs

— Tambalan
sumber

3

Pemahaman saya adalah bahwa itu /usr/localadalah versi lokal dari /usrsistem file, sedangkan /optplace holder untuk barang-barang misc

— Yasouser

5

Pertanyaan serupa di Ask Ubuntu , superuser

— kenchew

Di luar topik tentang alasan historis: Memahami bin, sbin, usr / bin, usr / sbin .

— Alexey

Linux: Direktori / opt vs / usr / local

— El borito

357

Sementara keduanya dirancang untuk berisi file yang bukan milik sistem operasi, /optdan /usr/localtidak dimaksudkan untuk berisi set file yang sama.

/usr/localadalah tempat untuk menginstal file yang dibangun oleh administrator, biasanya dengan menggunakan makeperintah (misalnya, ./configure; make; make install). Idenya adalah untuk menghindari bentrokan dengan file yang merupakan bagian dari sistem operasi, yang akan ditimpa atau ditimpa yang lokal sebaliknya (misalnya, /usr/bin/foomerupakan bagian dari OS sementara /usr/local/bin/foomerupakan alternatif lokal).

Semua file di bawah /usrdapat dibagikan di antara instance OS, meskipun ini jarang dilakukan dengan Linux. Ini adalah bagian di mana FHS sedikit kontradiktif dengan diri sendiri, seperti /usryang didefinisikan sebagai read-only, tetapi /usr/local/binperlu dibaca-tulis agar instalasi perangkat lunak lokal dapat berhasil. Standar sistem file SVR4, yang merupakan sumber inspirasi utama FHS, merekomendasikan untuk menghindari /usr/localdan menggunakan /opt/localsebagai gantinya untuk mengatasi masalah ini.

/usr/localadalah warisan dari BSD asli. Pada saat itu, kode sumber /usr/binperintah OS berada di /usr/src/bindan /usr/src/usr.bin, sedangkan sumber perintah yang dikembangkan secara lokal berada di /usr/local/src, dan binari mereka di /usr/local/bin. Tidak ada gagasan tentang pengemasan (di luar tarbal).

Di sisi lain, /optadalah direktori untuk menginstal paket tidak terikat (yaitu paket bukan bagian dari distribusi Sistem Operasi, tetapi disediakan oleh sumber independen), masing-masing dalam subdirektori sendiri. Mereka sudah membangun seluruh paket yang disediakan oleh distributor perangkat lunak pihak ketiga yang independen. Tidak seperti /usr/localbarang-barang, paket-paket ini mengikuti konvensi direktori (atau setidaknya seharusnya demikian). Sebagai contoh, someappakan dipasang di /opt/someapp, dengan salah satu perintahnya /opt/someapp/bin/foo, file konfigurasinya akan berada /etc/opt/someapp/foo.conf, dan file log-nya /var/opt/someapp/logs/foo.access.

— Jlliagre
sumber

53

/ usr / local, untuk perangkat lunak mandiri, internal, terkompilasi dan dipelihara. / opt adalah untuk area instalasi bundel biner / aplikasi non-mandiri, eksternal, paket. Hmmm ... kita tidak punya file program C: \ untuk semuanya ;-)

— Nikhil Mulley

2

"Di lain pihak, / opt adalah direktori tempat menginstal paket tidak terikat" Apa arti paket 'tidak terikat' di sini?

— Kevin Wheeler

1

@KevinWheeler Itu dijelaskan dalam kalimat berikutnya. Tidak mengikat berarti paket bukan bagian dari distribusi Sistem Operasi tetapi disediakan oleh sumber independen.

— jlliagre

2

@jlliagre the centos docs * state "Misalnya, jika direktori / usr / di-mount sebagai bagian NFS read-only dari host jarak jauh, masih mungkin untuk menginstal paket atau program di bawah direktori / usr / local /" Saya tidak tahu siapa yang benar, tetapi ini tampaknya bertentangan dengan klaim Anda tentang area di mana FHS lemah. (* source centos.org/docs/5/html/5.1/Deployment_Guide/… )

— Kevin Wheeler

1

@KevinWheeler Itulah kelemahan yang saya maksud. Memasang paket atau program di direktori yang jauh dan hanya-baca tidak mungkin dilakukan. Solusinya adalah me-mount sistem file lokal di / usr / local tapi ini lebih mirip pekerjaan sementara daripada sesuatu yang dirancang dengan baik.

— jlliagre

84

Perbedaan mendasarnya /usr/localadalah untuk perangkat lunak yang tidak dikelola oleh pemaket sistem, tetapi masih mengikuti aturan penyebaran unix standar.

Itu sebabnya Anda punya /usr/local/bin, /usr/local/sbin /usr/local/includedll ...

/optdi sisi lain adalah untuk perangkat lunak yang tidak mengikuti ini dan digunakan secara monolitik. Ini biasanya termasuk perangkat lunak komersial dan / atau lintas-platform yang dikemas dalam gaya "Windows".

— Biarkan aku menjadi
sumber

12

Saya tidak setuju tentang poin monolitik Anda. Standar FHS mengatakan paket yang diinstal di / opt subdirektori harus memiliki file spesifik host mereka diinstal di luar / opt, masing-masing di bawah / etc / opt / package untuk file konfigurasi dan / var / opt / paket untuk log, spool dan sejenisnya. / opt sebenarnya lebih dekat dengan aturan penyebaran unix daripada / usr / local, yang meletakkan segala sesuatu di bawah direktori yang seharusnya hanya-baca tetapi tidak bisa karena alasan yang jelas.

— jlliagre

5

Tentu, jika saya membuat paket opt dan ingin mengklaim kepatuhan FHS. Kalau tidak, standarnya lebih dari apa yang Anda sebut "pedoman". Hanya karena NetBeans tidak menggunakan / etc / opt / netbeans tidak akan membuat saya tidak memasukkannya ke / opt untuk seluruh sistem atau $ HOME / .local / opt untuk pengguna tunggal.

— jla

1

@ jla Saya menganggap komentar terakhir Anda diarahkan kepada saya jadi silakan gunakan @ xxx ketika membalas kepada orang lain bahwa OP atau penulis balasan. Tentang / etc / opt, FHS tidak mengatakan itu adalah lokasi yang direkomendasikan (sebagai pedoman) tetapi lokasi wajib. Anda atau pengembang Netbeans bebas untuk melanggar standar itu karena tidak ada wewenang untuk menegakkannya, tetapi jangan katakan melakukan kesalahan adalah cara yang harus dilakukan. Itu hanya kesalahpahaman yang disayangkan atau pelanggaran yang disengaja.

— jlliagre

8

@ jlliagre Sebagai administrator sistem saya, FHS adalah seperangkat pedoman. Direktori / opt adalah akal sehat yang didirikan dengan baik untuk meletakkan perangkat lunak monolitik / opt / <package> atau / opt / <provider>. Ketika saya menginstal paket yang ingin menggunakan <package | provider> / all / data / required / to / support, itu akan memilih / bahkan jika penyedia gagal mengikuti setiap detail dari FHS terbaru. Saya mungkin mengirim email atau melaporkan bug, tetapi saya tidak akan meletakkan paket monolitik di tempat lain agar merasa lebih baik tentang FHS di sistem saya.

— jla

1

@ jlliagre Saya telah menginstal banyak hal di / opt dan tidak ada file yang dibuat di / etc / opt. Harus?

— erm3nda

18

Mereka memang sangat mirip, dan penggunaan satu atau yang lain lebih merupakan masalah pendapat. Jurnal Linux mengadakan diskusi titik / tandingan ini tentang topik yang tepat di sini .

— philfr
sumber

9

Oh sayang. Aku tidak bermaksud menyeret diriku ke "perang suci".

— Tambalan

13

Bagi saya, secara pribadi, itulah yang dikatakan Bill di tautan @ philfr:

Pada sistem pengembangan, atau kotak pasir, memiliki direktori / opt di mana Anda bisa melempar sesuatu dan melihat apakah mereka bekerja masuk akal. Saya tahu saya tidak akan melalui upaya pengemasan barang sendiri untuk mencobanya. Jika aplikasi tidak berhasil, Anda dapat dengan mudah rm direktori / opt / mytestapp dan aplikasi itu adalah sejarah. Pengemasan mungkin masuk akal ketika Anda menjalankan penyebaran besar (ada kalanya saya melakukan paket aplikasi), tetapi sering kali, senang melemparkan barang ke / opt.

Sayangnya, sebagian besar make installskrip mendorong file ke dalam /usr/localalih-alih hanya membuat symlink di sana: - /

— pepoluan
sumber

2

Apa gunanya? Jika Anda ingin membuat symlink, mengapa tidak meletakkan file asli saja di tempat pertama?

— Let_Me_Be

8

Hanya untuk mengomentari make installtarget memasukkan file ke /usr/local; fungsi ini mudah berubah dengan melewati sebuah --prefix=parameter baris perintah ke ./configurenaskah, atau jika tidak ada ./configurenaskah, Anda dapat melewatkan parameter ke makesasaran seperti: make --prefix=/usr install.

— Sean C.

3

Apakah / opt direktori standar termasuk dalam $ PATH? Saya tahu / usr / lokal.

— LawrenceC

5

@Let_Me_Jadi manfaatnya adalah sangat mudah menyimpan versi yang lebih lama. Katakanlah saya memiliki 2 versi 'foo', terletak di /opt/foo-1.1dan /opt/foo-1.2. Saat saya memutakhirkan, foosymlink dalam /usr/local/binpoin ke foo-1.2. Jika karena alasan tertentu saya perlu mengembalikan, saya hanya mengganti symlink dengan yang menunjuk ke foo-1.1. Jika 1.2 baik-baik saja setelah beberapa minggu, cepat rm -rf /opt/foo-1.1menghapus versi yang lebih lama dengan cepat dan bersih.

— pepoluan

7

@ultrasawblade tidak, tidak. dan tidak seharusnya. setelah semua, menurut FHS, / opt harus dibagi lagi menjadi subdir yang menyandang nama paket. menjejalkan semuanya ke dalam PATH adalah cara yang pasti untuk bencana. alih-alih, aplikasi harus menginstal sendiri di bawah / opt, dan symlinks program yang dibuat pengguna ke / usr / local / bin (atau sbin).

— pepoluan

11

Pertama, saya kira tidak ada jawaban yang tegas; administrator yang berbeda akan memiliki pendapat yang berbeda, sesuai dengan latar belakang mereka. Secara historis, /usr/localprioritas utama; itu adalah kebaktian di Berkley, IIRC. Pada satu titik selama pengembangan Sistem V, jika saya tidak salah (ini semua sudah lama sekali, dan saya tidak mencatat), ada keputusan atau keinginan untuk dapat me /usr- mount hanya-baca, yang berarti Anda tidak dapat menambahkan perangkat lunak baru ke dalamnya; mungkin itulah sebabnya /opt ditemukan. Ketika itu terjadi, ada begitu banyak perangkat lunak yang ada yang menulis untuk /usride itu tidak pernah benar-benar turun.

Preferensi pribadi saya adalah /opt, dengan subdirektori terpisah untuk setiap produk; ini membuat menghapus produk kasus sederhana rm -fr. Tetapi jika semua perangkat lunak Anda diinstal melalui manajer paket yang baik, itu tidak masalah, dan jika perangkat lunak yang Anda instal tidak sepenuhnya mematuhi konvensi ini, dan menulis konfigurasi dan semacamnya di suatu tempat di bawah /usr, tidak masalah juga, meskipun untuk alasan yang berlawanan.

— James Kanze
sumber

1

"" "semua perangkat lunak Anda diinstal melalui manajer paket yang" "" tidak mungkin kecuali Anda hanya menggunakan perangkat lunak yang sering digunakan.

— Pacerier

1

@Pacerier dimungkinkan, tergantung distro apa yang Anda gunakan. Apa pun perangkat lunaknya, mungkin ada di Arch User Repository, dan jika tidak, PKGBUILD relatif mudah untuk ditulis.

— StarlitGhost

9

Saya memiliki pandangan yang sedikit berbeda tentang masalah ini.
Sementara segala sesuatu di jlliagre 's jawabannya benar, aplikasi praktis bagi saya, ketika deploying software dalam sebuah cluster, turun ke variabel lingkungan default dan penggunaan kembali default libs.

Sederhananya - /usr/localdan semua direktori anaknya berada di env vars yang sesuai seperti PATHdan MANPATH, dan /usr/local/lib{,64}berada di ldconfig's ( /etc/ld.so.conf.d/).

/opt/OTOH tidak - yang menguntungkan ketika membutuhkan beberapa versi atau paket yang saling bertentangan untuk hidup berdampingan dalam sistem, tetapi membutuhkan semacam manajemen lingkungan (mis. Koleksi modul-lingkungan atau perangkat lunak ), dan tidak menguntungkan karena berpotensi "membuang" "Ruang penyimpanan dengan menduplikasi pustaka bersama, karena setiap instalasi di /optdapat sepenuhnya lengkap.

Untuk sifat /usr/localkerja bersama, diasumsikan bahwa misalnya biner dipasang langsung ke /usr/local/bin(dan halaman manual yang sesuai /usr/local/share/man/...) daripada /usr/local/app/{bin,share/man,...}dll.

— Dani_l
sumber