Haruskah saya memasukkan aplikasi ke / usr / local atau / usr / local / share?

Apa "standar" - yang harus saya masukkan aplikasi (bukan hanya biner, tetapi seluruh distribusi) ke / usr / local atau / usr / local / share.

Misalnya scala atau weka - ini berisi contoh, binari, perpustakaan, dan sebagainya. Jadi itu akan terjadi

/usr/local/scala-2.9.1 

atau

/usr/local/share/scala-2.9.1

Karena saya satu-satunya admin, ini bukan masalah besar bagi saya, tetapi saya lebih suka menggunakan sesuatu yang banyak digunakan, bukan dengan kebiasaan saya sendiri.

Penting: Saya tidak bertanya tentang kasus, di mana Anda harus membagi aplikasi menjadi / usr / local / bin, / usr / local / lib dan sebagainya. Sebaliknya saya bertanya tentang case ketika Anda harus menyimpan satu direktori utama untuk seluruh aplikasi.

Saya pikir / opt lebih standar dalam konteks semacam ini. Bagian yang relevan dalam Filesystem Hierarchy Standard dikutip di bawah ini.

Distribusi dapat menginstal perangkat lunak dalam / opt, tetapi tidak boleh memodifikasi atau menghapus perangkat lunak yang diinstal oleh administrator sistem lokal tanpa persetujuan administrator sistem lokal.

 Dasar Pemikiran Penggunaan / opt untuk perangkat lunak tambahan adalah praktik yang sudah mapan dalam komunitas UNIX. Antarmuka Biner Aplikasi System V [AT&T 1990], berdasarkan pada Definisi Antarmuka System V (Edisi Ketiga), menyediakan struktur / opt yang sangat mirip dengan yang didefinisikan di sini.

Intel Binary Compatibility Standard v. 2 (iBCS2) juga menyediakan struktur serupa untuk / opt.

Secara umum, semua data yang diperlukan untuk mendukung paket pada suatu sistem harus ada dalam / opt /, termasuk file yang dimaksudkan untuk disalin ke / etc / opt / dan / var / opt / serta direktori yang dipesan di / opt.

Pembatasan kecil pada distribusi menggunakan / opt diperlukan karena konflik mungkin antara perangkat lunak yang diinstal distribusi dan yang diinstal secara lokal, terutama dalam kasus nama path tetap yang ditemukan dalam beberapa perangkat lunak biner.

Struktur direktori di bawah ini / opt / diserahkan kepada pembuat paket perangkat lunak, meskipun disarankan bahwa paket diinstal di / opt // dan ikuti struktur yang serupa dengan pedoman untuk / opt / paket. Alasan yang sah untuk menyimpang dari struktur ini adalah untuk paket dukungan yang mungkin memiliki file yang diinstal di / opt // lib atau / opt // bin.

Anda hanya boleh menggunakan /usr/local/sharefile yang tidak spesifik untuk versi arsitektur / OS tertentu.

Setelah itu terserah Anda apakah Anda mendistribusikan file di antara subdir yang ada /usr/localatau jika Anda membuat direktori khusus baru di /usr/local(tetapi yang terakhir tidak akan ada pada executable PATH, the LD_LIBRARY_PATH, maupun the MANPATH).

Lihatlah FHS

Sampai /optmenjadi umum, tempat yang biasa adalah /usr/local/lib/<package>.

Saat memasang aplikasi lokal, ada beberapa opsi tergantung pada bagaimana Anda ingin mengakses dan memperbarui. Juga harus dicatat bahwa beberapa metode lebih mirip sistem yang sudah Anda miliki dan beberapa lebih ad-hoc. Saya akan menyarankan bahwa solusi "terbaik" adalah yang membuat segalanya lebih mudah untuk dikelola.

Saya telah membagi jawaban ini berdasarkan jumlah paket untuk membuat instalasi khusus. Pemisahan ini berdasarkan pengalaman saya sendiri. Pengalaman-pengalaman ini menimbang waktu yang diperlukan untuk mengelola paket dan risiko mengacaukan sesuatu. Saya tidak bermaksud bahwa saya memiliki pengetahuan tentang standar umum, tetapi memaksudkan ini sebagai titik rujukan yang harus diperhatikan ketika membuat keputusan.

Untuk hanya beberapa paket , saya ingin memasukkan paket tambahan /opt, di mana mereka berada di luar hal-hal lain sehingga tidak ada yang dapat mengacaukannya dan mereka dapat mengacaukan sesuatu yang lain. Ini adalah metode yang saya gunakan pada NAS saya. Namun metode ini menjaga binari dari PATH Anda, jadi Anda harus menambahkannya secara manual. Ini berfungsi dengan baik jika hanya ada beberapa paket untuk diinstal, tetapi menjadi sangat berantakan jika ada banyak.

Memperbarui di sini cukup mudah karena Anda cukup menimpa direktori.

Pro:

• sederhana
• cepat ke pengaturan
• tidak ada kesempatan untuk mempengaruhi bagian lain dari sistem
• uninstall semudah menginstal

Kekurangan:

• Menjadi agak membosankan jika jumlah paket untuk menginstal besar
• Membuatnya PATHterlihat berantakan

Untuk lebih dari beberapa paket , saya akan merekomendasikan menggunakan /usr/local/<your package>dan menghubungkan sym-executable dari /usr/local/binatau /usr/local/sbintergantung pada apakah Anda memerlukan hak akses root. Ini menyelamatkan Anda dari mengubah PATH Anda setiap kali sesuatu yang baru ditambahkan sehingga PATH tetap bersih. Ini adalah metode yang saya gunakan pada laptop Arch saya untuk semua paket non-pacman dan paket AUR.

Pembaruan dilakukan dengan menimpa direktori paket dan memeriksa apakah symlink masih valid dan memperbaiki jika tidak.

Pro

• Tidak membuat PATHberantakan
• Tidak memengaruhi sistem basis
• Masih sangat sederhana untuk menghapus semua add-on dan kembali ke sistem basis bersih

Kekurangan:

• Lebih banyak pekerjaan yang harus disiapkan
• Menghapus hanya satu paket memiliki beberapa pencarian yang harus dilakukan

Untuk banyak paket . Karena ini bukan kasus yang Anda inginkan, saya akan tetap singkat. Saya akan merekomendasikan membelah paket ke bin, lib, share, dll dan menginstal mereka untuk /usr/local. Ini untuk menjaga struktur tetap bersih. Anda juga dapat menentukan siapa yang dapat menulis di mana dan banyak lagi. Misalnya, Anda tidak ingin orang lain selain memodifikasi root executable.

Di sini pembaruan menjadi sedikit lebih rumit karena Anda perlu menulis lebih dari satu direktori. Saya akan merekomendasikan mengemas semuanya dan membiarkan manajer paket menangani sisanya.

Bagikan

The sharedirektori itu sendiri adalah untuk file independen arsitektur seperti yang tercantum dalam Faheem ini hubungan dan arsitektur tergantung file harus pergi ke lib, lib32, lib64, dll