/ Opt ve / usr / local arasındaki fark nedir?

Göre Dosya Sistemi Hiyerarşi Standardı , /opt"eklenti uygulama yazılım paketlerinin yüklenmesi" içindir. /usr/local"yerel olarak yazılım yüklerken sistem yöneticisi tarafından kullanım içindir". Bu kullanım durumları oldukça benzer görünüyor. Yazılım genellikle ya yüklemek için varsayılan olarak yapılandırılır dağılımları yer almayan /usr/localveya /opthangi seçtikleri bakımından hiçbir özel sebep ve mantık yokken.

Kaybettiğim bir fark var mı, yoksa her ikisi de aynı şeyi yapıyor, ancak tarihsel nedenlerden dolayı var mı?

Her iki işletim sistemine ait olmayan dosyaları içerecek şekilde tasarlanmıştır, iken /optve /usr/localaynı dosya kümesi içerecek şekilde amaçlanmamıştır.

/usr/localYönetici tarafından oluşturulan dosyaları, genellikle makekomutu kullanarak (örn ./configure; make; make install.) kurabileceğiniz bir yerdir . Buradaki düşünce, işletim sisteminin bir parçası olan ya da yerel dosyaların üzerine yazılacak ya da üzerine yazacak dosyalara çarpmamaktan kaçınmaktır (örneğin, yerel bir alternatif olsa da işletim sisteminin bir /usr/bin/fooparçasıdır /usr/local/bin/foo).

/usrBu, Linux ile nadiren yapılmasına rağmen, altındaki tüm dosyalar işletim sistemi örnekleri arasında paylaşılabilir. Bu, FHS'nin /usrsalt okunur olarak tanımlandığı gibi biraz çelişkili olduğu, ancak /usr/local/binyerel yazılım kurulumunun başarılı olması için okunması gereken bir bölüm . FHS'nin ana ilham kaynağı olan SVR4 dosya sistemi standardı, bu sorunun üstesinden gelmekten kaçınmak /usr/localve kullanılmasını tavsiye ediyor /opt/local.

/usr/localorijinal BSD’den kalan bir miras. O zaman, kaynak kodu /usr/binişletim sistemi komutları vardı /usr/src/binve /usr/src/usr.binyerel olarak geliştirilmiş komutların kaynağı iken /usr/local/srcve onların ikili içinde /usr/local/bin. Ambalaj kavramı (tarball'ların dışında) yoktu.

Öte yandan, /opther biri kendi alt dizininde, birleştirilmiş paketleri (yani, İşletim Sistemi dağıtımının bir parçası olmayan, ancak bağımsız bir kaynak tarafından sağlanan paketler) yüklemek için bir dizindir. Bunlar zaten bağımsız bir üçüncü taraf yazılım distribütörü tarafından sağlanan bütün paketleri inşa ediyorlar. /usr/localBunların aksine , bu paketler dizin kurallarını takip eder (ya da en azından onlar gerekir). Örneğin, someappyüklü olacak /opt/someapponun komuta olmanın biriyle, /opt/someapp/bin/fookendi yapılandırma dosyası olacağını /etc/opt/someapp/foo.confve bunun günlük dosyaları içinde /var/opt/someapp/logs/foo.access.

Temel fark, /usr/localsistem paketleyicisi tarafından yönetilmeyen, ancak standart unix dağıtım kurallarını izleyen yazılımlar içindir.

Bu yüzden sahipsin /usr/local/bin, /usr/local/sbin /usr/local/includevb ...

/optÖte yandan, bunu takip etmeyen ve yekpare bir biçimde konuşlandırılmış bir yazılım içindir. Bu genellikle "Windows" tarzında paketlenmiş ticari ve / veya platformlar arası yazılımı içerir.

Gerçekten çok benzerler ve birinin ya da diğerinin kullanımı daha fazla bir fikir meselesi. Linux dergi tam bu konu hakkında bu nokta / kontrpuan tartışma vardı burada .

Benim için, şahsen, Bill'in @ philfr'ın linkinde söylediği:

Bir geliştirme sisteminde veya bir sanal alanda, şeyleri fırlatıp çalışıp çalışamayacağını görebileceğiniz / opt dizinine sahip olmak çok mantıklı geliyor. Bunları denemek için bir şeyleri paketleme çabasına girmeyeceğimi biliyorum. Uygulama çalışmazsa, / opt / mytestapp dizinini basitçe rm olarak kullanabilirsiniz; bu uygulama tarihçelidir. Paketleme, büyük bir dağıtım çalıştırırken anlamlı olabilir (uygulamaları paketlediğim zamanlar vardır), ancak çoğu zaman, / opt içine malzeme atmak güzeldir.

Ne yazık ki, çoğu make installkomut dosyası dosyaları /usr/localorada bir sembolik bağlantı kurmak yerine içine iter : - /

İlk önce kesin bir cevap olduğunu sanmıyorum; farklı yöneticiler, geçmişlerine göre farklı görüşlere sahip olacaklardır. Tarihsel olarak /usr/localönce geldi; IIRC Berkley’de yapılan toplantıydı. Sistem V'in gelişimi sırasında bir noktada yanılmıyorsam (bu çok uzun zaman önceydi ve not almadım), /usrsalt okunur bir şekilde bağlayabilmek için bir karar ya da bir istek vardı , bu, ona yeni bir yazılım ekleyemediğiniz anlamına gelir; bu neden /opt icat edilmiş olabilirdi. Olduğu gibi /usr, bu fikre hiç yazmayan, gerçekten hiçbir zaman gerçek olmayan bir yazılım vardı .

Benim kişisel tercihim, /opther ürün için ayrı bir alt dizin; Bu, bir ürünün çıkarılmasını basit bir durum haline getirir rm -fr. Ancak, yazılımınızın tamamı iyi bir paket yöneticisi tarafından kurulursa, farketmez, ve kurduğunuz yazılım kesinlikle bu kurallara uymuyorsa ve yapılandırmaları ve altındaki herhangi bir yere yazıyorsa /usr, bunun da önemi yoktur. tam tersi nedenlerden dolayı.

Bu konuda biraz farklı bir yaklaşımım var. Jlliagre 'in cevabındaki
her şey doğru olsa da, benim için pratik uygulama, bir kümede yazılım dağıtırken, varsayılan ortam değişkenleri ve liblerin varsayılan olarak yeniden kullanımı ile ilgilidir.

Basitçe söylemek gerekirse - /usr/localve tüm alt dirs uygun env gibi vars içindedir PATHve MANPATHve /usr/local/lib{,64}içindedir Ldconfig en ( /etc/ld.so.conf.d/).

/opt/OTOH - sistemde birlikte var olmak için birden fazla sürüm veya çakışan paketler gerektiğinde avantajlıdır, ancak bir tür çevre yönetimi gerektirir (örneğin, çevre modülleri veya yazılım koleksiyonları ) ve potansiyel olarak "israf etmesi dezavantajlıdır msgstr "paylaşılan kütüphaneleri kopyalayarak saklama alanı, çünkü her kurulum /opttamamen kendi içinde olabilir.

Ortak doğası için /usr/localişe, örneğin ikili doğrudan yüklenir varsayılır /usr/local/bin(ve adam uygun kaynaklarına sayfalarda /usr/local/share/man/...) ziyade /usr/local/app/{bin,share/man,...}vb