4. /usr
Hiyerarşisi
4.1. Amaç
/usr
, dosya sisteminin ikinci ana bölümüdür.
/usr
paylaşılabilir, salt okunur veridir. Bu,
/usr
'nin çeşitli FHS uyumlu konaklar arasında
paylaşılabilir olması ama üzerine yazılmaması gerektiği anlamına gelir.
Konağa özgü veya zaman zaman değişen herhangi bir bilgi başka bir yerde
depolanmalıdır.
Büyük yazılım paketleri, /usr
hiyerarşisi altında
doğrudan bir alt dizin kullanmamalıdır.
4.2. Gereksinimler
Aşağıdaki dizinlerin ve bu dizinlere sembolik bağların
/usr
içinde bulunması gereklidir:
Dizin | Açıklama |
---|---|
bin
|
Çoğunluğu kullanıcı komutudur |
lib
|
Kütüphaneler |
local
|
Yerel hiyerarşi (ana kurulum sonrası boştur) |
sbin
|
Yaşamsal olmayan sistem ikil dosyaları |
share
|
Mimariye bağımlı olmayan veriler |
4.3. Özel Seçenekler
Dizin | Açıklama |
---|---|
games
|
Oyunlar ve eğitici ikil dosyalar (seçimlik) |
include
|
C yazılımlarına dahil edilen başlık dosyaları |
libexec
|
Diğer uygulamalar tarafından çalıştırılan ikil dosyalar (seçimlik) |
lib
|
Özel amaçlı kütüphaneler (seçimlik) |
src
|
Kaynak kodlar (seçimlik) |
Nispeten önemli bir örnek ve geniş kabul gören bir uygulama olması nedeniyle X Pencere Sistemi için bir istisna yapılmıştır.
Dizinler için aşağıdaki sembolik bağlar olabilir. Bu olasılık, tüm
dağıtımların /var
hiyerarşisini kullandığı
varsayılana kadar eski sistemlerle uyumluluğu koruma ihtiyacına
dayanmaktadır.
/usr/spool -> /var/spool /usr/tmp -> /var/tmp /usr/spool/locks -> /var/lock
Bir sistem yukarıdaki sembolik bağlardan herhangi birini artık gerektirmediğinde, istenirse bağ kaldırılabilir.
4.4. /usr/bin
4.4.1. Amaç
Bu, sistemdeki çalıştırılabilir komutların birincil dizinidir.
4.4.2. Gereksinimler
/usr/bin
alt dizin içermemelidir.
4.4.3. Özel Seçenekler
İlgili alt sistem kuruluysa, aşağıdaki dosyaların ve bu dosyalara
sembolik bağların /usr/bin
içinde bulunması gerekir:
Komut | Açıklama |
---|---|
perl | Pratik Çıkarma ve Rapor Dili (seçimlik) |
python | Python yorumlama dili (seçimlik) |
tclsh | Tcl yorumlayıcı içeren basit kabuk (seçimlik) |
wish | Basit Tcl/Tk pencere kabuğu (seçimlik) |
expect | Etkileşimli iletişim kutusu uygulaması (seçimlik) |
Gerekçe
Çalıştırılabilir betiklerin çoğunda, betiği çalıştıracak yorumlayıcı,
betik dosyasının ilk satırında
#!
biçeminde belirtilir. Bu tür betikleri farklı sistemler arasında
taşınabilir kılmak için yorumlayıcı konumlarını standart hale getirmenin
getirileri vardır. Kabuk yorumlayıcısı, bu belirtim tarafından
yorumlayıcı-mutlak-yolu
/bin
içine zaten sabitlenmiştir, ancak Perl,
Python, Tcl ve wait için yorumlayıcılar çeşitli yerlere kurulabilir.
Burada belirtilen konumlar, yorumlayıcıların fiziksel konumuna sembolik
bağ olarak gerçeklenebilir.
4.5. /usr/include
4.5.1. Amaç
Burası, C yazılımlama dili için sistemin tüm genel kullanım başlık dosyalarının yerleştirilmesi gereken yerdir.
4.5.2. Özel Seçenekler
İlgili alt sistem kuruluysa, aşağıdaki dizinlerin ve bu dizinlere
sembolik bağların /usr/include
içinde bulunması
gerekir:
Dizin | Açıklama |
---|---|
bsd | BSD uyumluluğu başlık dosyaları (seçimlik) |
4.6. /usr/lib
4.6.1. Amaç
/usr/lib
nesne dosyalarını ve kütüphanelerini
içerir.[22]
Bazı sistemlerde, /usr/lib
doğrudan kullanıcılar
veya kabuk betikleri tarafından çalıştırılması amaçlanmayan ikil
dosyaları da içerebilir.[23]
Uygulamalar, /usr/lib
altında tek bir alt dizin
kullanabilir. Bir uygulama bir alt dizin kullanıyorsa, uygulama
tarafından özel olarak kullanılan mimariye bağlı tüm veriler bu alt
dizine yerleştirilmelidir.[24]
4.6.2. Özel Seçenekler
Tarihsel nedenlerden dolayı, /usr/lib/sendmail, eğer varsa, sistemin posta aktarım aracısı tarafından sağlanan sendmail-uyumlu komuta sembolik bağ olmalıdır.[25] [26]
4.7. /usr/libexec
4.7.1. Amaç
/usr/libexec
doğrudan kullanıcılar veya kabuk
betikleri tarafından yürütülmesi amaçlanmayan dahili ikil dosyaları
içerir.
/usr/libexec
'i bu şekilde kullanan uygulamalar,
/usr/lib
'i burada belgelenen diğer amaçlar için
kullansalar bile dahili ikil dosyaları depolamak için
/usr/lib
kullanmamalıdır.
Gerekçe
Bu belgenin önceki bazı sürümleri, bazı ortamlarda standart uygulama olmasına rağmen /usr/libexec
'i desteklemiyordu.[27]
Bu kısıtlamaya uyum sağlamak için, bunun yerine
/usr/lib
kullanmak yaygın bir uygulama haline
geldi. Her iki uygulama da artık kabul edilebilir, ancak her uygulama
kendini yapılandırmak için bir yol seçmelidir.
4.8. /usr/lib
<nitelik>
4.8.1. Amaç
/usr/lib
<nitelik>
belli bir amaca yönelik olması dışında /usr/lib
ile aynı görevi yerine getirir. Buna
/usr/lib
<nitelik>
/sendmail
ve /usr/lib
<nitelik>
/X11
sembolik bağlarının gerekliliği dahil değildir.[28]
4.9. /usr/local
4.9.1. Amaç
/usr/local
hiyerarşisi, yazılımı yerel olarak
kurarken sistem yöneticisi tarafından kullanılır. Sistem yazılımı
güncellendiğinde üzerine yazılmaması gereken kurulumlar içindir.
Bir grup konak arasında paylaşılabilen ancak /usr
altında bulunmayan uygulamalar ve veriler için de kullanılabilir.
/usr
altındaki yazılımı değiştirmeyecek veya
yükseltmeyecekse yerel olarak kurulan yazılım /usr
yerine /usr/local
içine
yerleştirilmelidir.[29]
4.9.2. Gereksinimler
Aşağıdaki dizinler veya bu dizinlere sembolik bağların
/usr/local
içerisinde bulunması gereklidir:
Dizin | Açıklama |
---|---|
bin
|
Yerel ikil dosyaları |
etc
|
Yerel ikil dosyalar için konağa özgü sistem yapılandırması |
games
|
Yerel oyun ikil dosyaları |
include
|
Yerel C başlık dosyaları |
lib
|
Yerel kütüphaneler |
man
|
Yerel çevrimiçi kılavuzlar |
sbin
|
Yerel sistem ikil dosyaları |
share
|
Yerel mimariden bağımsız hiyerarşi |
src
|
Yerel kaynak kodları |
FHS uyumlu bir sistem ilk kez kurulduktan sonra, aşağıda listelenenler
dışında hiçbir dizin /usr/local
dizininde olamaz.
4.9.3. Özel Seçenekler
/lib
<nitelik>
veya
/usr/lib
<nitelik>
dizinleri mevcutsa, bunlara eşdeğer dizinlerin ayrıca
/usr/local
altında da bulunması gerekir.
/usr/local/etc
, /etc/local
dizinine sembolik bağ olabilir.
Gerekçe
/usr/local/etc
tutarlılığı kurulumcular için
faydalıdır ve diğer sistemlerde zaten kullanılmaktadır. Bir sistemi
yeniden oluşturmak için tüm /usr/local
dizininin
de yedeklenmesi gerektiğinden, ek bakım yükü getirmez, ancak sistemler
tüm yapılandırmalarını tek bir hiyerarşi altında istiyorsa,
/etc/local
dizinine bir sembolik bağ uygundur.
/usr/etc
'ye hala izin verilmediği unutulmamalıdır:
/usr
içindeki uygulamalar yapılandırma dosyalarını
/etc
içine yerleştirmelidir.
/usr/share/color
dizini bu belgede belirtildiği gibi
mevcutsa, /usr/local/share/color
dizini de
/usr/share/color
ile aynı kurallara tabi olarak
mevcut olmalıdır.
Gerekçe
Bu kullanım, sistem yöneticisine gerektiğinde renk profillerini elle olarak kurmak için yer sağlar.
4.10. /usr/sbin
4.10.1. Amaç
Bu dizin, yalnızca sistem yöneticisi tarafından kullanılan zorunlu
olmayan ikil dosyaları içerir. Sistem onarımı, sistem kurtarma,
/usr
bölümünün bağlanması veya diğer temel
işlevler için gerekli olan sistem yönetim araçları bunun yerine
/sbin
içine yerleştirilmelidir.[30]
4.10.2. Gereksinimler
/usr/sbin
içinde alt dizin olmamalıdır.
4.12. /usr/src
4.12.1. Amaç
Kaynak kod, yalnızca başvuru amacıyla bu alt dizine yerleştirilebilir.[38]
[22]
Mimariden bağımsız, uygulamaya özgü, duruk dosya ve alt dizinler
/usr/share
dizinine yerleştirilmelidir.
[23]
Çalıştırılabilir ikili dosyalar için /usr/lib
ile /usr/libexec
karşılaştırması için aşağıdaki
/usr/libexec
bölümüne
bakınız.
[24]
Örneğin, Perl 5 modülleri ve kitaplıkları için
perl5
alt dizini.
[25]
makewhatis ve sendmail gibi
bazı komutlar da geleneksel olarak /usr/lib
dizinine yerleştirilmiştir. makewhatis dahili bir
ikil dosyadır ve bir ikil dizinine yerleştirilmelidir; kullanıcılar
yalnızca catman'e erişir. Daha yeni
sendmail ikil dosyaları artık öntanımlı olarak
/usr/sbin
dizinine yerleştirilmektedir.
Ek olarak, sendmail uyumlu bir posta aktarım
aracısı kullanan sistemler, sendmail komutu olarak,
yürütülebilir dosyanın kendisine veya uygun yürütülebilir bir dosyaya
sembolik bağ olarak /usr/sbin/sendmail'i
sağlamalıdır.
[26]
X Pencere Sistemi için konağa özgü veriler
/usr/lib/X11
'de saklanmamalıdır.
xorg.conf
gibi konağa özgü yapılandırma
dosyaları /etc/X11
'de saklanmalıdır.
Bu, daha genel bir yapılandırma dosyasına (muhtemelen
/usr/lib/X11
'de) yalnızca sembolik bağ yapılmış
olsa bile, system.twmrc
gibi yapılandırma
verilerini de içerir.
[27] Örneğin, Özgür Yazılım Vakfı tarafından sağlanan "GNU Kodlama Standartları"na bakılabilir.
[28]
/usr/lib
ve
/usr/lib
aynı olduğunda (biri diğerine sembolik bağ ise), bu dosyalar ve bu
uygulamaların alt dizinleri de mevcut olacaktır.
<nitelik>
[29]
/
veya /usr
dizinine
yerleştirilen yazılımların üzerine sistem yükseltmeleri yazılabilir
(yine de bu koşullar altında dağıtımların /etc
dizinindeki verilerin üzerine yazmamasını öneririz). Bu nedenle yerel
yazılımlar sebepsiz yere /usr/local
dışına
yerleştirilmemelidir.
[30]
Yerel olarak kurulan sistem yönetim uygulamaları
/usr/local/sbin
altına yerleştirilmelidir.
[31]
Bu verilerin çoğu başlangıçta /usr
(man
, doc
) veya
/usr/lib
(dict
,
terminfo
, zoneinfo
)
altında saklanırdı.
[32]
Açıkçası, /
içinde kılavuz sayfaları yoktur, çünkü bunlar önyükleme sırasında veya acil durumlarda gerekli değildir. Gerçekten.
[33]
Örneğin, /usr/share/man
altında 4. bölümde
(Aygıtlar) hiç kılavuz sayfası yoksa
/usr/share/man/man4
dizini olmayabilir.
[34] Bu kuralın önemli bir istisnası, ISO 3166'da 'GB' olan, ancak çoğu e- posta adresi için 'UK' olan Birleşik Krallık'tır.
[35]
/usr/local/man
dizininin kullanımı artık
önerilmemektedir ve bu belirtimin sonraki sürümlerinde tamamen
kullanımdan kaldırılabilir.
[36]
Böyle dosyalardan bazıları:
airport
, birthtoken
,
eqnchar
, getopt
,
gprof.callg
, gprof.flat
,
inter.phone
, ipfw.samp.filters
,
ipfw.samp.scripts
, keycap.pcvt
,
mail.help
, mail.tildehelp
,
man.template
, map3270
,
mdoc.template
, more.help
,
na.phone
, nslookup.help
,
operator
, scsi_modes
,
sendmail.hf
, style
,
units.lib
, vgrindefs
,
vgrindefs.db
, zipcodes
.
[37]
Tarihsel olarak, magic
dosyası
/usr/share/misc
dizinine yerleştirildi, ancak
file komutunun günümüzdeki sürümleri birkaç dosya
kullanmakta ve bunları /usr/share/file
dizinine
yerleştirmektedir. Uyumluluk için dağıtım,
/usr/share/misc/magic
adında
/usr/share/file/magic
dosyasına sembolik bağ
oluşturabilir.
[38] Genelde, kaynak kod bu hiyerarşi içinde derlenmemelidir.