Neden paylaşılan bir kitaplığın birden çok sürümünü yükleyemiyorum?

Genellikle belirli bir programın xy kitaplığı sürümüne ve xz'de başka bir programa bağlı olacağı durumlar vardır, ancak bildiğim kadarıyla, hiçbir paket yöneticisi hem xy hem de xz'yi yüklememe izin vermeyecektir Bazen her iki ana sürüme de (örneğin qt4 ve qt5, aynı anda yüklenebilir), ancak (görünüşte) asla küçük sürümler değildir.

Bu neden? İçinde olduğu gibi, onu engelleyen sınırlayıcı faktör nedir? Bu kullanışlı işlevselliğe izin vermemek için iyi bir neden olması gerektiğini düşünüyorum. Örneğin, paylaşılan bir nesneyi yüklerken hangi sürümün yükleneceğini belirten bir alan yok ve bu nedenle Linux'un hangisinin yükleneceğine nasıl karar vereceğini bilmesi mümkün değil mi? Yoksa bunun için gerçekten bir sebep yok mu? Tüm küçük sürümlerin yine de uyumlu olması gerekiyordu gibi bir şey?

Aslında, düzgün bir şekilde yapılırsa, paylaşılan kitaplığın birden çok sürümünü yükleyebilirsiniz.

Paylaşılan kitaplıklar genellikle şu şekilde adlandırılır:

lib<name>.so.<api-version>.<minor>

Ardından, aşağıdaki adlar altında kütüphaneye sembolik bağlar vardır:

lib<name>.so
lib<name>.so.<api-version>

Bir geliştirici bir ikili dosya oluşturmak için kütüphaneye bağlandığında .so, bağlayıcının bulduğu dosya adıdır. Gerçekten herhangi bir zamanda <name>aynı anda yüklenmiş olanlardan sadece biri olabilir, ancak bu sadece bir geliştiricinin aynı anda bir kütüphanenin birden fazla farklı sürümünü hedefleyemeyeceği anlamına gelir. Paket yöneticileriyle bu .sosymlink, -devyalnızca geliştiricilerin yüklemesi gereken ayrı bir paketin parçasıdır .

Bağlayıcı, adı biten bir dosya bulduğunda .sove onu kullandığında, bu kitaplığın içinde soname adlı bir alan arar . Soname, bağlayıcıya, sonuçta elde edilen ikili dosyaya hangi dosya adının gömüleceğini ve böylece çalışma zamanında hangi dosya adının aranacağını bildirir. Soname'nin ayarlanması gerekiyor lib<name>.so.<api-version>.

Bu nedenle, çalışma zamanında dinamik bağlayıcı bunu arayacak lib<name>.so.<api-version>ve kullanacaktır.

Amaç şudur:

• <minor>yükseltmeler kütüphanenin API'sini değiştirmez ve <minor>daha yüksek bir sürüme getirildiğinde, tüm ikili dosyaların yeni sürüme yükseltilmesine izin verilir. İkili dosyalar, lib<name>.so.<api-version>en son yüklenen bir simge bağlantısı olan ad altında kitaplığı lib<name>.so.<api-version>.<minor>aradıklarından, yükseltme işlemini alırlar.
• <api-version>yükseltmeler kitaplığın API'sını değiştirir ve mevcut ikili uygulamaların yeni sürümü kullanmasına izin vermek güvenli değildir. <api-version>Değiştirilmesi durumunda , bu uygulamalar adı aradığından, lib<name>.so.<api-version>ancak farklı bir değere sahip <api-version>olduklarından, yeni sürümü almayacaklardır.

Paket yöneticileri genellikle aynı kitaplığın birden fazla sürümünü aynı dağıtım sürümünde paketlemez, çünkü kitaplığı kullanan tüm ikili dosyalar da dahil olmak üzere tüm dağıtım, dağıtımdan önce her kitaplığın tutarlı bir sürümünü kullanmak üzere derlenir yayınlandı. Her şeyin tutarlı olduğundan ve bir dağıtımdaki her şeyin diğer her şeyle uyumlu olduğundan emin olmak, distribütörler için iş yükünün büyük bir parçasıdır.

Ancak, sisteminizi rahatsızlığınızın bir sürümünden diğerine yükselttiyseniz ve daha eski kitaplık sürümleri gerektiren bazı eski paketleriniz varsa, kitaplığın birden çok sürümüyle kolayca sonuçlandırabilirsiniz. Misal:

• eski bir Debian libmysqlclient16 içerir libmysqlclient.so.16.0.0ve içerir libmysqlclient.so.16.
• Geçerli Debian'dan libmysqlclient18 , içerir libmysqlclient.so.18.0.0ve sembolik bağlar libmysqlclient.so.18.

Bu işleve izin verilmez, çoğu kitaplığın numaralandırılma şeklinin bir sonucu olarak ve paket adı değişikliklerinin rahatsızlığı nedeniyle çok yaygın değildir.

Noktalı sürüm numarası şeması kullan XYZ "Mikro" sürüm Z sıklıkla hata düzeltmelerinde değişirse, geriye doğru uyumlu değişikliklerde "küçük" Y sayısı değişir ve "büyük" sürüm numarası X API değişikliklerinde değişir (ve bazen büyük ekstra işlevsellik).

En son hataların düzeltilmesini istememenizin hiçbir nedeni olmamalı ve geriye dönük uyumlu değişiklikler de yazılımınızı bozmamalıdır.

Kütüphane bu şekilde geliştirilirse, XYZ'yi X ile (Y + m) değiştirebilmelisiniz. (Z + n). herhangi bir m ve n için. Yani kütüphanenizi her zaman aynı büyük sayı serisindeki en sonlarla değiştirebilmelisiniz. Ve kütüphane geliştiricileri dikkatliyse ve bir sonraki büyük sayı uyumluysa (örneğin, şeyleri kullanımdan kaldırma duyurusu ile ancak henüz kaldırmama), bir sonraki büyük sayıyı bile kullanabilirsiniz.

Paket geliştiricileri için bu, yalnızca paketi güncelleyerek size en son sürümü vermek için adı yalnızca biriyle veya hatta numara adıyla kullanamayacakları anlamına gelir. Onlar bir paket içinde bir kütüphane gönderirseniz abc2o zaman kendi yazılımlarını taşımak için çemberin içinden gitmek zorunda dayanıyordu üzerinde abc2kullanıma yükseltmek için abc3geçiş paketleri ile bazen. Bağımlı paketlerin çoğunda işe yararsa, ana sürüm numarasını bir kitaplıktan çıkarmak daha uygundur. Bu nedenle, her ikisi de abc2ve abc3bir dağıtımda mevcut olan bir noktada mevcut olsa bile abc3, genellikle çağrılır abc( henüz henüz abc2olmadığı zaman çağrılır gibi abc3) ve abc2dağıtım içinde hiçbir paket bağımlı olmadığında düşmek mümkün olurabc2 tamamen.

Numaralandırma şeması tekdüze takip edilmez, ancak sadece internetin gelişiyle, böyle bir şemanın nasıl kullanılacağı hakkında bilgi yayılması ve kütüphane kullanıcılarının (dağıtım geliştiricileri dahil) önemli uyumlulukları önemli olmayan kütüphanede bulunan bir CHANGES dosyasını okumak zorunda kalmanız, bunun daha yaygın hale gelmesine katkıda bulunmuştur.

Karşılık gelen örneklerden biri, ancak kitaplığın değil, paylaşılan nesnelerinde ve küçük sayı değişikliklerinde dekapaj formatıyla uyumlu olmayan python yorumlayıcısıdır. Bu nedenle python (2.7 serisinin en yenisi) ve python3 (şu anda python3.4 serisinin en yenisi) için paketlerin yanı sıra python 2.6 (daha az yaygınlaşmayan) ve python 3.3 için açık paketler göreceksiniz.