Yazılım neden / usr / lib dizinine yüklenir?


11

Yıllardır Linux sunucuları kullanıyorum ve Dosya Sistemi Hiyerarşi Standardı tarafından karıştırılmaya devam ediyorum. Genellikle karışıklıkla yaşayabilirim. Ama şimdi Linux için kendi yazılımımı geliştirdiğime göre, paket yöneticileri tarafından nereye kurulacağını anlamam gerekiyor.

/ Opt uygulamam için mükemmel bir yer olduğuna oldukça ikna oldum. Ama Debian dosya sistemimi araştırdıktan sonra artık emin değilim: / usr / lib! Birkaç isim vermek gerekirse: MySQL, MySQLWorkbench, Nautilus, Rythmbox ...

FHS'ye göre, / usr / lib dosyasının "Programlama ve paketler için kütüphaneler" ve "kullanıcılar veya kabuk komut dosyaları tarafından doğrudan yürütülmesi amaçlanmayan nesne dosyaları, kütüphaneler ve dahili ikili dosyaları içerdiği" varsayılır ( Buraya bakınız ).

Debian sunucumun / usr / lib dosyasında bulunan birçok yazılım, kütüphaneler veya dahili ikili dosyalar değil, tam teşekküllü kullanıcı yürütülebilir yazılımlarıdır!

Uygulamamın / opt. Ama bunun doğru olup olmadığını ve her şeyden önce nedenini anlamak istiyorum .

Nazik tavsiyeleriniz için şimdiden teşekkürler,

Eric.


2
Nokta kontrolü, ne söyleyebilirim ki MySQLWorkbench sadece / usr / lib altındaki kütüphaneleri kurar. / Usr / lib dosyasında "tam teşekküllü kullanıcı yürütülebilir yazılımı" olduğunu düşündüren nedir?
Mark Wagner

Uygulama menüsünde bulunan gerçek kısayol, doğru hatırlarsam / usr / lib içinde bulunan bir ikili dosyaya işaret eder.
Eric MORAND

Listelediğiniz yazılımın nereye kurulduğu konusunda karışık görünüyorsunuz. İşte MySQL ve Nautilus dosyaları için listelemelere bağlantılar. FHS olması gerektiği gibi dosyaların / etc, / usr / bin, / usr / lib vb. Arasında bölündüğüne dikkat edin. packages.debian.org/wheezy/i386/mysql-server-5.5/filelist packages.debian.org/wheezy/i386/nautilus/filelist
Sciurus

Yanıtlar:


6

Dosya Sistemi Heirarchy Standardını anlamanın gerçek anahtarı, ağ dosya sistemleri göz önünde bulundurularak tasarlandığını bilmektir.

Aynı işletim sisteminin, sürümün ve mimarinin her makinesi için, NFS aracılığıyla / usr'ı paylaşabilir ve bağlayabilirsiniz.
/ usr, ağ yığını başlatıldıktan sonra (yeniden) bağlanır.

/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

Yerel / uzak ve r - r / w standartları için bir bağlantı sağlamayı düşünür müsünüz?
Kaptan Zürafa

Bu, bir ağdaki her Linux sunucusu veya iş istasyonu için tek bir / usr "havuzu" olabileceği anlamına mı geliyor?
Eric MORAND

1
Biraz iş gerektiriyor, ama evet yapabilirsiniz. Sabit diskler pahalı olduğunda geri bu herhangi bir büyük sunum için norm oldu.
Dan Garthwaite

@ eric-morand FHS'den: "/ usr dosya sisteminin ikinci büyük bölümüdür. / usr paylaşılabilir, salt okunur verilerdir. Bu, / usr'in çeşitli FHS uyumlu ana bilgisayarlar arasında paylaşılabilir olması ve . Ana bilgisayara özgü veya zamanla değişen bilgiler başka bir yerde saklanır. " pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Dan Garthwaite

Whoops. Yukarıdaki yorum @CaptainGiraffe
Dan Garthwaite

12

Aradaki fark, sistemin bir parçası olarak/usr kurulu paketleri tutmak anlamına geliyor . Debian / Ubuntu depolarından, PPA'lardan vb. Aldığınız paketler buraya gidin. İken ayrıştırılmış içindir üçüncü şahıs dağıtımın paket dağıtım sürecinde dağıtılan değildir uygulamaların./opt

.Deb veya .rpm paketlerini dağıtırsanız, sonunda yazılımınızı resmi depolara dahil etmeye yönelik bir göz ile, yüklemeniz gerekir /usr. Aksi takdirde adresine yükleyin /opt. Her iki durumda da, uygulamanız herhangi bir keyfi konumda (örneğin GNU otoklavlarının yardımıyla) çalışacak şekilde derlenebilmelidir.


Teşekkürler. Şu anda uygulamamın resmi veri havuzunda yer alması gibi bir planım yok.
Eric MORAND

Peki ya / usr / local? Yoksa ayrık mı
Aaron Copley

@AaronCopley /usr/localbu sorunun kapsamına girmedi . Ancak, yerel yöneticinin derlediği ve yüklediği üçüncü taraf yazılımlar içindir.
Michael Hampton

Bu yüzden ayrık kabul edilip edilmeyeceğini sordum.
Aaron Copley

2

Kitaplıklarınızı <prefix>/lib, ikili dosyalarınızı <prefix>/bin, başlık dosyalarınızı <prefix>/include, man sayfalarınızı prefix/[share/]man, pkgconfig dosyalarınızı <prefix>/lib/pkgconfigveya <prefix/share/pkgconfigcmake .m4 dosyalarınızı<prefix>/share/aclocal

Ardından paket yöneticisinin önek üzerinde karar vermesine izin verin. Rpm / deb's'i kendiniz dağıtıyorsanız, /usrbir önek için iyi bir seçimdir.

./configure --prefix=~/.local/ Hala çalışmalı, bu yüzden yolunuzu herhangi bir yere hardcoding gitmeyin lütfen!

Bazı kütüphaneler, onları aynı zamanda bir kütüphane olarak çalıştırılabilir ve kullanılabilir hale getiren başka bir araca sarılır, ancak hala kütüphanelerdir ve $ PATH'nızda değiller, bu yüzden onları / lib'de onaylamak tamam.


1

/ Opt altında uygulamanızı yüklemekten kaçınmanızı öneririm. Neden 1: Bazı dağıtımlarda varsayılan olarak / opt yoktur Neden 2: / usr / lib kütüphaneler için standart bir yoldur {Diğer uygulamaların kütüphanenizi kullanması gerekiyorsa, kütüphane yolunuzu / etc / ldconfig} / opt dizinine manuel olarak eklemeniz gerekir manuel olarak yüklediğiniz ve nerede bulunduğunu bilmek istediğiniz bağımsız uygulamalarınız olduğunda daha kullanışlıdır

Tam teşekküllü yürütülebilir dosyaların / usr / lib altında bulunmasının nedenlerinden biri, diğer komut dosyalarından kullanılması olabilir. {Örneğin bash komut dosyaları doğrudan bir API kullanamaz. bu nedenle ortak bir hile bu api etrafında bir "sarmalayıcı" oluşturmak ve komut dosyası argümanları olarak parametreleri itmek}


2
Katılmıyorum. / Opt dizinine kurmak istiyorsa, paket yöneticisi dizini yaratacaktır, dolayısıyla bu bir sorun değildir. Ayrıca, / usr / lib dizinine kurulan ikili dosyalar kötü bir fikirdir.
Walter

Teşekkürler @Nikolaidis Fotis. Ancak benim durumumda, uygulamam bir halk kütüphanesi içermiyor ve diğer uygulamalar tarafından kullanılmayacak.
Eric MORAND

0

Lütfen / opt dizinine kurun.

Çok fazla Linux uygulaması, Windows geliştiricilerinin 90'larda yaptıklarıyla aynı şeyi yapar.

Eşyalarımızı C: \ windows'a yükleyelim, böylece kolay ve kolay bir şekilde (ve biraz daha hızlı). Daha sonra, farklı yazılım paketleri aynı kütüphanelerin farklı sürümlerine ihtiyaç duyduğundan (Windows'ta kütüphanelerin sürümüne sahip olmayan) 15 yıllık DLL cehennemi geldi.

Gerçek sistem yazılımı yazmıyorsanız, / opt'i koyun, böylece insanlar neyi kimin yüklediğini daha iyi izleyebilir.


4
Bu Windows değil. Biz o paket yöneticileri var işin ve bu gerçekten çok bir sorun değil.
Michael Hampton

Her şeyin aynı ağaçta olmasından endişe ediyorsanız, Nix paket yöneticisine göz atın . Bana sorarsan her iki dünyanın en iyisi.
TheSola10
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.