Mengapa perangkat lunak menginstal sendiri di / usr / lib?


11

Saya telah menggunakan server Linux selama bertahun-tahun sekarang dan saya terus menjadi bingung oleh Filesystem Hierarchy Standard. Biasanya, saya bisa hidup dengan kebingungan. Tetapi sekarang saya sedang mengembangkan perangkat lunak saya sendiri untuk Linux, saya perlu memahami di mana seharusnya diinstal oleh manajer paket.

Saya cukup yakin bahwa / opt adalah lokasi yang sempurna untuk aplikasi saya. Tetapi setelah menyelidiki filesystem Debian saya, saya tidak yakin lagi: banyak perangkat lunak yang sebenarnya diinstal di / usr / lib! Untuk beberapa nama: MySQL, MySQLWorkbench, Nautilus, Rythmbox ...

Menurut FHS, / usr / lib seharusnya berisi "Perpustakaan untuk pemrograman dan paket" dan "termasuk file objek, perpustakaan, dan binari internal yang tidak dimaksudkan untuk dijalankan secara langsung oleh pengguna atau skrip shell" ( Lihat di sini ).

Banyak perangkat lunak yang terletak di / usr / lib server debian saya bukan pustaka atau biner internal tetapi perangkat lunak yang dapat dieksekusi pengguna penuh!

Saya masih di jalur untuk menginstal aplikasi saya di / opt. Tetapi saya benar-benar ingin memahami apakah ini benar dan, di atas segalanya, mengapa .

Terima kasih sebelumnya atas saran Anda,

Eric.


2
Spot checking, dari apa yang saya tahu MySQLWorkbench hanya menginstal pustaka di bawah / usr / lib. Apa yang membuat Anda berpikir bahwa ada "perangkat lunak yang dapat dieksekusi pengguna penuh" di / usr / lib?
Mark Wagner

Pintasan aktual yang terletak di menu Aplikasi menunjuk ke biner yang terletak di / usr / lib, jika saya ingat dengan benar.
Eric MORAND

Anda tampaknya bingung tentang di mana perangkat lunak yang Anda daftarkan diinstal. Berikut ini tautan ke cantuman jika file untuk MySQL dan Nautilus. Perhatikan bahwa file-file tersebut dibagi antara / etc, / usr / bin, / usr / lib dll. Seperti yang dikatakan FHS. packages.debian.org/wheezy/i386/mysql-server-5.5/filelist packages.debian.org/wheezy/i386/nautilus/filelist
Sciurus

Jawaban:


6

Kunci nyata untuk memahami Heirarki Filesystem Standar adalah mengetahui bahwa itu dirancang dengan sistem file jaringan dalam pikiran.

Untuk setiap mesin dengan OS, rilis, dan arsitektur yang sama, Anda dapat berbagi / usr melalui NFS dan memasangnya.
/ usr dipasang (kembali) setelah tumpukan jaringan diinisialisasi.

/var <-- local, r/w optimized
/usr <-- can be mounted over network, possibly even read-only!
/opt <-- local, read mostly
/etc <-- local, read mostly
/srv <-- local, r/w optimized

/home <-- either/or

Maukah Anda memberikan tautan untuk standar lokal / jarak jauh dan r - r / w?
Kapten Giraffe

Apakah ini berarti bahwa seseorang dapat memiliki "repositori" tunggal / usr untuk setiap server Linux atau workstation dalam jaringan?
Eric MORAND

1
Butuh beberapa pekerjaan, tetapi ya, Anda bisa. Kembali ketika hard drive mana mahal ini adalah norma untuk peluncuran besar.
Dan Garthwaite

@ eric-morand Dari FHS: "/ usr adalah bagian utama kedua dari sistem file. / usr adalah data yang dapat dibagikan, hanya-baca. Itu berarti bahwa / usr harus dapat dibagikan antara berbagai host yang sesuai dengan FHS dan tidak boleh ditulis ke . Setiap informasi yang khusus untuk host atau bervariasi dengan waktu disimpan di tempat lain. " pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Dan Garthwaite

Aduh. Komentar di atas adalah untuk @CaptainGiraffe
Dan Garthwaite

12

Perbedaannya adalah /usrpaket-paket tersebut dimaksudkan untuk menahan instalasi sebagai bagian dari sistem . Paket yang Anda dapatkan dari repositori Debian / Ubuntu, PPA, dll., Buka di sini. Sedangkan /optdimaksudkan untuk aplikasi pihak ketiga yang tidak dibundel yang tidak didistribusikan melalui proses distribusi paket distribusi.

Jika Anda mendistribusikan paket .deb atau .rpm, dengan tujuan akhirnya mendapatkan perangkat lunak Anda termasuk dalam repositori resmi, Anda harus menginstalnya ke /usr. Jika tidak, instal ke /opt. Dalam kedua kasus tersebut, aplikasi Anda harus dapat dikompilasi untuk dijalankan di lokasi sembarang (mis. Dengan bantuan GNU autotools).


Terima kasih. Saat ini, saya tidak punya rencana untuk memasukkan aplikasi saya ke dalam repositori resmi.
Eric MORAND

Bagaimana dengan / usr / local? Atau diskrit itu
Aaron Copley

@AaronCopley /usr/localtidak berada dalam ruang lingkup untuk pertanyaan ini. Tetapi ini dimaksudkan untuk perangkat lunak pihak ketiga yang dikompilasi dan diinstal oleh administrator lokal.
Michael Hampton

Itu sebabnya saya bertanya apakah itu akan dianggap diskrit.
Aaron Copley

2

Anda menginstal perpustakaan Anda di <prefix>/lib, binari Anda di <prefix>/bin, file header Anda di <prefix>/include, halaman manual prefix/[share/]man, file konfigurasi pkg di <prefix>/lib/pkgconfigatau <prefix/share/pkgconfig, file cmake .m4 Anda di<prefix>/share/aclocal

Kemudian biarkan manajer paket memutuskan awalan. Jika Anda mendistribusikan sendiri rpm / deb, /usradalah pilihan yang baik untuk awalan.

./configure --prefix=~/.local/ Seharusnya masih berfungsi, jadi jangan pergi hardcoding jalan Anda di mana saja tolong!

Beberapa perpustakaan dibungkus dengan beberapa alat lain yang membuat mereka juga dapat dieksekusi dan dapat digunakan sebagai perpustakaan, tetapi mereka masih berupa perpustakaan, dan tidak dalam $ PATH Anda, jadi tidak apa-apa untuk memasukkannya ke / lib kurasa.


1

Saya akan menyarankan untuk menghindari menginstal aplikasi Anda di / opt. Alasan 1: Beberapa distro tidak memiliki / memilih secara default Alasan 2: / usr / lib adalah jalur standar untuk perpustakaan {Jika aplikasi lain perlu menggunakan perpustakaan Anda, Anda perlu menambahkan jalur perpustakaan Anda secara manual ke / etc / ldconfig} / opt lebih nyaman ketika Anda memiliki aplikasi mandiri yang Anda instal secara manual dan Anda ingin tahu di mana mereka berada

Salah satu alasan yang dapat dieksekusi sepenuhnya executable terletak di / usr / lib bisa jadi mereka digunakan dari skrip lain. {Misalnya skrip bash tidak dapat menggunakan API secara langsung. untuk alasan ini trik umum adalah membuat "wrapper" di sekitar api ini dan mendorong parameter sebagai argumen skrip}


2
Saya tidak setuju. Jika dia ingin menginstal di / opt, manajer paket akan membuat direktori, jadi itu bukan masalah. Juga, binari yang dipasang di / usr / lib adalah ide yang buruk.
Walter

Terima kasih @Nikolaidis Fotis. Namun dalam kasus saya, aplikasi saya tidak mengandung perpustakaan umum dan tidak akan digunakan oleh aplikasi lain.
Eric MORAND

0

Silakan instal di / opt.

Terlalu banyak aplikasi Linux membuat hal yang sama yang dibuat oleh pengembang Windows di tahun 90-an.

Mari kita instal barang-barang kami di C: \ windows sehingga sederhana dan mudah ditemukan (dan sedikit lebih cepat). Kemudian datang 15 tahun neraka DLL sebagai paket perangkat lunak yang berbeda membutuhkan versi berbeda dari pustaka yang sama (yang di Windows tidak memiliki versi pustaka).

Kecuali jika Anda menulis perangkat lunak sistem yang sebenarnya, letakkan di / opt, sehingga orang dapat melacak dengan lebih baik siapa yang menginstal apa.


4
Ini bukan Windows. Kami memiliki manajer paket yang berfungsi dan ini sebenarnya bukan masalah besar.
Michael Hampton

Jika Anda benar-benar khawatir tentang segala sesuatu yang berada di pohon yang sama, periksa manajer paket Nix . Terbaik dari kedua dunia, jika Anda bertanya kepada saya.
TheSola10
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.