Sự khác biệt giữa / opt và / usr / local là gì?

Theo Tiêu chuẩn phân cấp hệ thống tập tin , /optlà dành cho "việc cài đặt các gói phần mềm ứng dụng bổ trợ". /usr/locallà "để người quản trị hệ thống sử dụng khi cài đặt phần mềm cục bộ". Những trường hợp sử dụng có vẻ khá giống nhau. Phần mềm không được bao gồm trong các bản phân phối thường được cấu hình theo mặc định để cài đặt theo /usr/localhoặc /optkhông có vần điệu hoặc lý do cụ thể mà chúng chọn.

Có một số khác biệt tôi đang thiếu, hoặc cả hai đều làm điều tương tự, nhưng tồn tại vì lý do lịch sử?

Mặc dù cả hai đều được thiết kế để chứa các tệp không thuộc hệ điều hành /optvà /usr/localkhông có ý định chứa cùng một bộ tệp.

/usr/locallà nơi để cài đặt các tệp được xây dựng bởi quản trị viên, thường bằng cách sử dụng makelệnh (ví dụ ./configure; make; make install:). Ý tưởng là để tránh xung đột với các tệp là một phần của hệ điều hành, sẽ bị ghi đè hoặc ghi đè lên các tệp cục bộ nếu không (ví dụ: /usr/bin/foolà một phần của HĐH trong khi /usr/local/bin/foolà một thay thế cục bộ).

Tất cả các tệp bên dưới /usrcó thể chia sẻ giữa các phiên bản HĐH, mặc dù điều này hiếm khi được thực hiện với Linux. Đây là một phần trong đó FHS hơi mâu thuẫn, như /usrđược định nghĩa là chỉ đọc, nhưng /usr/local/bincần phải đọc-ghi để cài đặt phần mềm cục bộ để thành công. Tiêu chuẩn hệ thống tệp SVR4, vốn là nguồn cảm hứng chính của FHS, được khuyến nghị nên tránh /usr/localvà sử dụng /opt/localthay thế để khắc phục vấn đề này.

/usr/locallà một di sản từ BSD ban đầu. Vào thời điểm đó, mã nguồn của /usr/bincác lệnh OS nằm trong /usr/src/binvà /usr/src/usr.bin, trong khi nguồn của các lệnh được phát triển cục bộ nằm trong /usr/local/srcvà các nhị phân của chúng nằm trong /usr/local/bin. Không có khái niệm về bao bì (bên ngoài tarball).

Mặt khác, /optlà một thư mục để cài đặt các gói chưa được xử lý (tức là các gói không phải là một phần của phân phối Hệ điều hành, nhưng được cung cấp bởi một nguồn độc lập), mỗi gói trong thư mục con riêng của nó. Họ đã được xây dựng toàn bộ các gói được cung cấp bởi một nhà phân phối phần mềm độc lập của bên thứ ba. Không giống như /usr/localcông cụ, các gói này tuân theo các quy ước thư mục (hoặc ít nhất là chúng nên). Ví dụ, someappsẽ được cài đặt /opt/someapp, với một trong các lệnh /opt/someapp/bin/foocủa nó, tệp cấu hình của nó sẽ nằm trong /etc/opt/someapp/foo.confvà các tệp nhật ký của nó /var/opt/someapp/logs/foo.access.

Sự khác biệt cơ bản /usr/locallà dành cho phần mềm không được quản lý bởi bộ đóng gói hệ thống, nhưng vẫn tuân theo các quy tắc triển khai unix tiêu chuẩn.

Đó là lý do tại sao bạn có /usr/local/bin, /usr/local/sbin /usr/local/includev.v ...

/optmặt khác là dành cho phần mềm không tuân theo điều này và được triển khai theo kiểu nguyên khối. Điều này thường bao gồm phần mềm thương mại và / hoặc đa nền tảng được đóng gói theo kiểu "Windows".

Chúng thực sự rất giống nhau, và việc sử dụng cái này hay cái kia là vấn đề quan điểm hơn. Tạp chí Linux đã có cuộc thảo luận về điểm / điểm này về chủ đề chính xác này ở đây .

Đối với cá nhân tôi, đó là những gì Bill nói trong liên kết của @ philfr:

Trên một hệ thống phát triển, hoặc một hộp cát, có một thư mục / opt nơi bạn có thể chỉ cần ném mọi thứ và xem liệu chúng có hoạt động hay không. Tôi biết tôi sẽ không tự mình nỗ lực đóng gói mọi thứ để thử chúng. Nếu ứng dụng không hoạt động, bạn chỉ cần rm thư mục / opt / mytestapp và ứng dụng đó là lịch sử. Đóng gói có thể có ý nghĩa khi bạn đang triển khai một triển khai lớn (đôi khi tôi thực hiện các ứng dụng gói), nhưng rất nhiều lần, thật tuyệt khi ném công cụ vào / opt.

Thật không may, hầu hết make installcác tập lệnh đẩy các tập tin vào /usr/localthay vì chỉ tạo một liên kết tượng trưng ở đó: - /

Đầu tiên, tôi không nghĩ có một câu trả lời nghiêm ngặt; quản trị viên khác nhau sẽ có ý kiến ​​khác nhau, theo nền tảng của họ. Trong lịch sử, /usr/localđã đến đầu tiên; đó là hội nghị ở Berkley, IIRC. Tại một thời điểm trong quá trình phát triển Hệ thống V, nếu tôi không nhầm (điều này đã xảy ra từ lâu và tôi đã không ghi chú), đã có một quyết định hoặc mong muốn có thể chỉ /usrđọc, có nghĩa là bạn không thể thêm phần mềm mới vào nó; đó có thể là lý do tại sao /opt được phát minh Khi điều đó xảy ra, có rất nhiều phần mềm hiện có đã viết lên /usrý tưởng đó không bao giờ thực sự bắt đầu.

Sở thích cá nhân của tôi là /opt, với một thư mục con riêng cho mỗi sản phẩm; điều này làm cho việc loại bỏ một sản phẩm là một trường hợp đơn giản rm -fr. Nhưng nếu tất cả phần mềm của bạn được cài đặt thông qua trình quản lý gói tốt, thì điều đó không thành vấn đề và nếu phần mềm bạn cài đặt không tuân thủ nghiêm ngặt các quy ước này và viết các cấu hình và như vậy ở đâu đó /usr, thì điều đó cũng không thành vấn đề vì những lý do ngược lại.

Tôi có một chút khác biệt về vấn đề này.
Mặc dù mọi thứ trong câu trả lời của jlliagre đều đúng, nhưng ứng dụng thực tế đối với tôi, khi triển khai phần mềm trong một cụm, đi xuống các biến môi trường mặc định và sử dụng lại libs mặc định.

Nói một cách đơn giản - /usr/localvà tất cả các thư mục con của nó đều nằm trong các tệp env thích hợp như PATHvà MANPATH, và /usr/local/lib{,64}nằm trong ldconfig's ( /etc/ld.so.conf.d/).

/opt/OTOH không - cả hai đều có lợi khi yêu cầu nhiều phiên bản hoặc các gói xung đột cùng tồn tại trong hệ thống, nhưng yêu cầu một số loại quản lý môi trường (ví dụ: mô-đun môi trường hoặc bộ sưu tập phần mềm ) và bất lợi ở chỗ nó có khả năng "lãng phí "Không gian lưu trữ bằng cách sao chép các thư viện dùng chung, vì mỗi cài đặt trong /optcó thể hoàn toàn khép kín.

Đối với tính chất chung của /usr/localcông việc, giả định rằng ví dụ nhị phân được cài đặt trực tiếp vào /usr/local/bin(và trang man cho phù hợp /usr/local/share/man/...) chứ không phải /usr/local/app/{bin,share/man,...}v.v.